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ABSTRACT 


The  work  described  in  this  thesis  is  part  of  a  multi-year  research  project  to 
develop  an  Autonomous  Underwater  Vehicle  (AUV-II),  which  is  an  intelligent  robot 
submarine,  carried  out  by  the  departments  of  Mechanical  Engineering,  Computer 
Science,  and  Electrical  and  Computer  Engineering  of  the  Naval  Postgraduate  School. 

The  AUV-II  on-board  computer  must  perform  several  different  tasks  such  as 
navigation,  autopilot,  guidance,  sonar  processing,  and  collision  avoidance,  etc.  under 
strict  timing  constraints  to  guarantee  the  safety  of  the  vehicle.  This  thesis  describes 
the  design  and  development  of  real-time  scheduling  software,  which  is  capable  of 
scheduling  and  synchronizing  the  periodic  and  aperiodic  processes  required  by  the 
AUV-II.  A  design  recommendation  of  a  Graphical  User  Interface  has  been  developed 
to  improve  the  software  engineering  aspects  of  this  project. 
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I.  INTRODUCTION 


A.  BACKGROUND 

1.  NPS  AUV-II 

The  Naval  Postgraduate  School  is  currently  developing  an  Autonomous 
Underwater  Vehicle,  AUV-II,  which  is  an  intelligent,  robot  submarine.  Figure  1.1, 
which  has  been  provided  by  the  NPS  Computer  Science  Department,  displays  an 
internal  layout  of  the  AUV-II.  The  microprocessor  that  is  used  is  a  Motorola  68030 
with  2.5  Mbytes  of  RAM  and  4  Mbytes  of  EPROM,  centered  around  a  twelve  slot 
G-96  bus  supplied  by  the  GESPAC  corporation.  It  also  has  a  200  megabyte  hard 
disk,  parallel  and  serial  communication  ports,  and  analog  to  digital  and  digital  to 
analog  channels. 

The  operating  system  is  OS-9,  developed  by  Microware  Systems  Corpora¬ 
tion  [Ref.  GES88].  It  is  an  operating  system  designed  to  support  real-time  appli¬ 
cations.  It  has  a  built-in  editor,  file  system,  compilers,  ability  to  support  local  area 
networks,  etc.  The  real-time  features  that  OS-9  supports  are  timers,  process  cre¬ 
ation  and  deletion,  process  priority  assignment,  process  scheduler,  synchronization 
primitives  etc. 

2.  Data-flow  for  On-board  Processing 

The  AUV-II,  in  a  typical  mission,  needs  eight  processes  to  be  running. 
Six  of  them  are  periodic  and  two  aperiodic.  These  processes  must  communicate 
with  each  other  and  implement  the  flow  diagram  that  Fig.  1.2  displays  [Ref.  F191], 
The  periodic  processes  are:  execute  mission,  guidance,  autopilot,  process  sonar  data, 
navigation,  and  monitor  system  status.  They  are  executed  at  10  Hz.  Aperiodic 
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Figure  1.1:  Internal  layout  of  AUV-II. 
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processes  are:  avoid  obstacle  and  plan/replan  mission.  The  AUV-II,  by  executing 
these  processes  in  the  appropriate  order,  and  by  having  all  the  required  information 
from  its  sensors,  completes  its  mission  successfully.  The  main  sensors  with  which  the 
AUV-II  is  equipped  are  gyros  for  dead  reckoning  and  sonar  for  real-time  navigation 
and  target  identification. 

3.  AUV-II  Real-time  Programming  Environment 

At  present,  the  code  that  is  used  for  the  operation  of  the  AUV-II  is  a 
single  sequential  program.  This  program  mainly  consists  of  the  initialization  part 
and  a  loop.  In  the  initialization  part,  the  user  provides  the  operation  instructions. 
In  the  timed  main  loop,  the  program  executes  all  the  required  instructions  for  the 
AUV-II  operation.  Execution  in  a  single  loop  is  very  convenient  for  applications  that 
execute  only  a  few  tasks  at  the  same  frequency.  It  is  extremely  difficult  to  design  this 
loop  for  a  large  number  of  tasks,  especially  when  those  tasks  have  different  frequencies 
or  some  of  them  have  to  execute  in  an  aperiodic  fashion. 

This  study  separates  the  operation  instructions  from  the  main  program  to 
form  a  set  of  independent  tasks.  In  this  thesis,  the  words  task  and  process  are  used 
interchangeably.  The  main  program  consists  only  of  functions  that  are  needed  before 
the  start  of  the  execution.  The  user  has  only  to  specify  the  processes  that  the  AUV-II 
has  to  execute  and  initialize  the  execution  values.  Since  the  user  of  this  program  is 
likely  not  to  be  an  expert  in  real-time  systems,  a  user  interface  capable  of  hiding  all 
the  details  from  the  user  is  created. 

The  whole  design  is  based  on  the  currently  used  hardware  platform  but 
effort  has  been  made  to  make  the  software  compatible  with  future  hardware  upgrade. 
In  case  this  is  not  possible,  the  general  ideas  of  the  design  are  selected  in  such  a  way 
that  they  can  be  used  even  under  major  hardware  modifications.  As  an  example, 
the  selection  of  the  OS-9  PIPE  as  a  synchronization  primitive  that  is  discussed  in 
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Chapter  III,  is  still  valid  if  the  host  computer  is  replaced  by  a  transputer  board,  and 
the  use  of  pipes  is  replaced  with  the  use  of  messages. 

B.  OBJECTIVES  OF  THE  STUDY 

This  thesis  is  a  continuation  of  [Ref.  Le91],  in  which  a  scheduler  capable  of 
scheduling  independent  periodic  processes  according  to  the  rate  monotonic  algo¬ 
rithm  was  created.  The  objectives  of  this  thesis  are: 

•  Create  a  scheduling  scheme  capable  of  scheduling  periodic  and  aperiodic  pro¬ 
cesses. 

•  Provide  the  required  synchronization  in  processes  dependent  on  each  other. 

•  Study  the  effect  of  the  synchronization  on  schedulability  under  rate  monotonic 
algorithm. 

•  Verify  the  capability  of  the  scheduling  scheme  to  be  used  in  the  AUV-II. 

•  Design  a  framework  for  a  Graphical  User  Interface  (GUI)  that  will  be  used  when 
the  current  host  computer  is  replaced  by  a  portable  workstation. 

C.  THESIS  ORGANIZATION 

Chapter  II  presents  the  scheduling  and  synchronization  requirements  of  real¬ 
time  systems.  It  also  presents  how  the  schedulability  is  affected  by  the  synchroniza¬ 
tion.  Chapter  III  presents,  the  implementation  of  scheduling  and  synchronization 
selected  for  the  AUV-II  in  detail.  This  chapter  also  presents  the  performance  of  the 
selected  scheduling  scheme  together  with  the  experiments  that  are  used  to  verify  the 
performance.  Chapter  IV  presents  a  design  of  a  Graphical  User  Interface  that  can  be 
implemented  when  the  current  computer  is  replaced  by  a  portable  workstation.  Fi¬ 
nally  Chapter  V  concludes  what  this  study  has  achieved  and  provides  some  directions 
for  further  improvement. 


5 


II.  ISSUES  IN  REAL-TIME  SYSTEMS 

A  computer  system  is  called  real-time  when  it  can  support  the  execution  of  real¬ 
time  applications.  Real-time  applications  differ  from  ordinary  computer  applications 
because  they  have  strict  timing  requirements.  These  requirements  almost  always  are 
connected  with  deadlines  of  the  tasks,  which  is  the  time  that  a  task  has  to  finish  its 
computation.  Deadlines  can  be  either  hard  or  soft.  If  the  results  of  a  computation 
are  useless  after  the  deadline,  it  is  called  hard;  if  their  validity  only  starts  to  degrade 
then  it  is  called  soft. 

In  most  real-time  applications,  more  than  one  task  has  to  run  at  the  same  time. 
It  is  easy  to  handle  that  if  one  processor  is  assigned  for  every  task.  In  uniprocessor 
applications  like  the  AUV-II,  this  cannot  happen.  For  that  purpose,  a  multitasking 
operating  system  that  fakes  multiple  processors,  like  OS-9  does,  has  to  be  selected. 

A.  REAL-TIME  SCHEDULING 

Whenever  more  than  one  task  is  runnable,  there  has  to  be  a  mechanism  that 
decides  which  one  to  run  first.  This  decision  mechanism  can  be  a  part  of  the  operating 
system,  it  can  be  a  process  outside  the  operating  system  called  as  application  sched¬ 
uler,  or  it  can  be  a  part  of  the  running  tasks.  Its  objective  is  to  assist  the  scheduler  in 
the  operating  system  according  to  the  application  requirements.  It  is  one  of  the  most 
important  parts  in  a  real-time  application  because  the  decisions  of  the  scheduler  will 
determine  how  the  computation  time  of  the  processor  is  going  to  be  used  in  the  most 
effective  way,  and  therefore,  if  any  deadlines  are  going  to  be  missed. 

Complete  analysis  of  the  different  scheduling  algorithms  can  be  found  in  [Ref. 
Ta87j.  As  reported  therein,  a  scheduling  algorithm,  in  order  to  be  effective,  has 
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to  be  priority  driven ,  and  not  priority  independent.  This  is  because  all  tasks  are 
not  equally  important  at  a  specific  time  and  because  priority  independent  scheduling 
cannot  provide  any  guarantees  that  the  timing  constraints  are  satisfied.  The  algorithm 
has  to  be  preemptive ,  as  against  run  to  completion ,  in  order  to  stop  a  task  that  is 
being  executed  for  a  more  important  one  in  such  a  way  that  as  few  deadlines  as 
possible  are  missed. 

1.  Static  Scheduling 

A  scheduling  algorithm  is  said  to  be  static  or  fixed  if  the  priority  is  assigned 
once  in  the  process  (probably  before  the  beginning  of  the  application)  [Ref.  LA90]. 
An  example  of  a  static  algorithm  is  the  rate  monotonic  algorithm  [Ref.  LL73].  These 
algorithms  can  guarantee  only  average  performance,  since  the  decision  of  the  scheduler 
is  based  on  the  assigned  priorities  and  not  on  the  current  conditions.  For  periodic 
tasks,  the  priorities  are  assigned  according  to  a  predetermined  characteristic  like  the 
period.  For  aperiodic  tasks,  the  priority  is  also  assigned  according  to  predetermined 
characteristics,  but,  depending  on  whether  the  deadlines  are  hard  or  soft,  either  the 
average  value  or  the  worst  case  value  can  be  used. 

2.  Dynamic  Scheduling 

A  scheduling  algorithm  is  said  to  be  dynamic  or  time  driven  when  the 
priority  can  change  with  time.  Examples  of  dynamic  algorithms  are  earliest  deadline , 
minimal  laxity,  etc.  These  algorithms  have  a  better  performance  than  static  ones. 
Most  of  the  dynamic  algorithms  handle  the  periodic  and  aperiodic  tasks  in  the  same 
way,  since  the  decision  of  the  scheduler  is  based  on  the  current  conditions.  The  main 
drawback  in  the  dynamic  algorithms  is  that  they  are  difficult  to  implement. [Ref. 
LA90] 
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3.  Rate  Monotonic  Scheduling 

As  has  been  shown  by  Liu  and  Layland,  the  optimum  fixed  priority  schedul¬ 
ing  algorithm  is  the  one  that  assigns  priorities  to  a  set  of  independent  tasks  according 
to  their  request  rate;  the  higher  the  request  rate,  the  higher  the  priority  [Ref.  LL73]. 
This  is  known  as  rate  monotonic  priority  assignment. 

The  rate  monotonic  algorithm  can  ensure,  for  n  independent  tasks,  that  all 
the  deadlines  will  be  met  if  the  conditions  of  the  theorem  proved  by  Liu  and  Layland 
are  met  [Ref.  LL73].  It  states  that 

the  upper  bound  to  processor  utilization  u  for  a  set  of  n  independent  tasks 
is  given  by: 

«  =  E^<n(2i-l)  (2.1) 

1  =  1 

where  C,  is  the  execution  time  and  T,  the  period  of  the  i  process. 


It  is  possible  to  increase  the  CPU  utilization  and  still  meet  all  the  deadlines. 


This  is  specified  by  the  theorem  [Ref.  LSD89]  which  states  that 

a  set  of  n  independent  periodic  tasks  scheduled  by  the  rate  monotonic  al¬ 
gorithm  will  always  meet  its  deadlines  if: 


«  T 

Vi,  1  <  i  <  n,  min 

~  ~  lTk 


in 

n 


<  i 


(2.2) 


where  Ri  =  {(Ar, /)|1  <  k  <  i,l  =  1,...,  the  period  and  Uj  the 

process  utilization  of  the  i  process. 


Although  the  rate  monotonic  algorithm  is  not  the  optimal  scheduling  al¬ 
gorithm,  it  is  very  important  for  the  following  reasons: 

•  The  most  important  task,  in  an  independent  set  of  tasks,  will  meet  its  deadlines 
even  under  temporary  overload. 

•  It  provides  fast  response  time  for  the  aperiodic  tasks,  while  it  is  able  to  meet  all 
the  deadlines  for  the  periodic  tasks.  This  is  of  great  importance  for  the  AUV-II 
where  some  of  the  tasks  are  aperiodic. 

•  The  priorities  can  be  modified  in  such  a  way  that  the  required  synchronization 
between  the  tasks  can  be  achieved. 

•  It  can  be  used  to  schedule  tasks  where  computation  time  is  known  imprecisely, 
as  in  many  AUV-II  algorithms. 


8 


Figure  2.1:  Timing  mechanism  for  two  independent  sets. 


4.  Data-flow  Scheduling 

Data-flow  scheduling  is  completely  different  from  the  previously  defined  al¬ 
gorithms  because  it  does  not  need  any  real-time  application  scheduler.  In  this  scheme 
of  scheduling,  the  start  of  the  execution  of  a  process  is  triggered  by  receipt  of  input 
data.  The  basic  advantage  of  data-flow  scheduling  is  that  it  combines  synchronization 
among  tasks  with  scheduling.  Other  scheduling  algorithms,  on  the  other  hand,  are 
designed  for  independent  tasks  and  incorporate  additional  schemes  for  synchroniza¬ 
tion. 

In  data-flow  scheduling,  if  processes  have  to  execute  in  a  periodic  fashion, 
a  timing  mechanism  has  to  be  inserted  for  each  independent  set  of  processes.  This 
mechanism  can  be  either  a  delay  in  one  of  the  processes  or  an  extra  process,  as  in 
Fig.  2.1,  that  will  implement  only  the  periodicity.  This  causes  all  the  other  processes 
that  depend  on  this  process  to  also  keep  the  periodicity.  Data-flow  scheduling  can 
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be  used  even  for  independent  processes,  if  each  process  is  handled  as  an  independent 
set.  This  is  not  efficient  because  processor  time  is  spent  on  each  individual  timing 
mechanism  and  the  set  of  tasks  becomes  bigger  causing  slower  process  switching. 

All  the  previously  outlined  scheduling  algorithms  can  be  used  in  conjunc¬ 
tion  with  data-flow  scheduling  in  order  to  make  a  selection  for  the  next  process  to  run 
w’hen  more  than  two  processes  are  ready  to  be  executed.  This  can  happen  in  the  case 
where  more  than  one  independent  set  of  processes  is  being  executed,  as  in  Fig.  2.1, 
or  even  in  the  same  set  when  more  than  two  independent  processes  exist.  Data-flow 
scheduling  is  suitable  for  applications  like  AUV-II  where  all  the  processes  are  closely 
dependent  and  only  one  timing  mechanism  can  achieve  the  required  frequency  of 
execution.  The  required  data  consistency  is  intrinsic  to  the  scheduler. 

5.  Schedulability  Analysis 

Schedulability  analysis  is  the  process  of  verifying  if  a  given  set  of  tasks  can 
meet  its  deadlines  when  using  a  specific  scheduling  algorithm  [Ref.  TK88].  The  use 
of  a  schedulability  analyzer  is  very  important  because  it  provides  a  tool  to  predict  if 
a  specific  set  of  tasks  can  be  used  before  the  actual  execution. 

In  order  to  carry  out  schedulability  analysis,  certain  basic  information 
about  the  tasks  is  required  regadless  of  the  scheduling  algorithm.  This  informa¬ 
tion,  for  periodic  tasks,  is  the  execution  time  and  the  period.  For  aperiodic  tasks, 
it  depends  on  the  deadlines.  If  the  deadlines  are  hard,  the  execution  time,  worst 
case  interarrival  interval,  and  expected  response  time  are  needed.  If  the  deadlines 
are  soft,  the  execution  time,  mean  period,  standard  deviation  of  the  period,  and  ex¬ 
pected  response  time  are  needed.  In  general,  this  information  is  called  attributes  of  a 
task.  The  results  required  from  the  schedulability  analysis  are  the  CPU  utilization, 
prediction  of  any  possible  missed  deadlines,  tasks  which  are  going  to  m'ss  a  deadline, 
and  expected  response  time. 
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B.  REAL-TIME  SYNCHRONIZATION 

The  tasks  of  a  real-time  application  are  not  usually  independent.  These  depen¬ 
dencies  arise  from  the  need  for  communication  between  the  processes  to  synchronize 
with  each  other  for  correct  and  fai  sharing  of  logical  or  physical  resources.  Since  each 
task  has  some  limited  time  bounds  within  which  it  has  to  be  executed,  these  de¬ 
pendencies  make  the  timing  requirements  more  stringent.  These  requirements  result 
in  a  reduced  utilization  of  the  processor  leading  to  an  increased  number  of  missed 
deadlines  for  a  given  processor  load.  It  is  important  to  use  the  right  synchronization 
protocol  in  order  to  provide  the  highest  possible  utilization,  and  at  the  same  time, 
avoid  some  undesirable  situations  like  priority  inversion,  where  a  high  priority  task 
is  blocked  by  a  lower  priority  task  for  an  unpredictable  period  of  time  [Ref.  SRL91]. 

In  most  real-time  applications,  processes  which  are  working  together  write  and 
read  the  same  shared  data.  This  can  cause  race  conditions ,  in  which  multiple  processes 
try  to  use  the  shared  data  with  unpredictable  results.  The  only  way  to  avoid  race 
conditions  is  to  achieve  mutual  exclusion,  that  is,  when  a  process  is  using  the  shared 
data,  others  are  excluded  from  using  it.  Our  objective  is  to  provide  synchronization 
that  avoids  race  conditions  and  maintains  data  consistency.  Data  consistency  prevents 
a  process  from  using  the  shared  data  before  it  is  updated.  There  are  various  primitives 
which  facilitate  such  synchronization,  such  as: 

Semaphores:  A  semaphore  is  a  variable  with  integer  values,  usually  only  0  and  1 
[Ref.  Di88,  Ta87j.  Semaphores  can  be  used  in  such  a  way  that  0  means  that 
the  shared  data  has  not  be  updated  or  someone  else  is  using  the  shared  data 
and  1  means  that  the  new  data  is  available  and  no  one  else  is  using  it.  Since 
the  semaphores  are  always  supported  by  hardware  instructions  like  TEST  AND 
SET  LOCK,  mutual  exclusion  is  guaranteed. 
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Monitors:  Monitors  are  programming  language  constructs  that  group  together  vari¬ 
ables,  data  structures,  and  procedures  [Ref.  Ta87].  The  most  important  prop¬ 
erty  of  the  monitors  is  that  they  provide  mutual  exclusion  without  any  further 
design  by  the  programmer.  When  a  process  is  using  a  monitor,  all  other  pro¬ 
cesses  that  compete  for  access  to  the  monitor  are  suspended  until  the  monitor 
is  not  in  use.  With  proper  use  of  the  variables  or  with  one  more  semaphore,  the 
desired  data  consistency  can  also  be  achieved. 

Events:  Events  are  a  special  kind  of  variable  [Ref.  Di88].  The  values  of  events 
(E)  change  only  with  instructions  supported  by  hardware,  like  Signal(E)  and 
Wait(E).  Proper  use  of  event  instructions  causes  a  process  to  be  executed  only 
if  the  required  conditions  have  been  met.  As  a  result,  both  mutual  exclusion 
and  data  consistency  can  be  achieved. 

Pipes:  Pipes  are  sequential  files  which  never  leave  the  system’s  RAM  memory  [Ref. 
DiSS] .  Usually  these  files  are  small,  since  data  stays  there  till  a  process  reads 
from  the  pipe.  What  makes  pipes  useful  is  that,  if  a  process  tries  to  read  from 
an  empty  pipe,  it  is  suspended  until  some  other  process  puts  data  in  the  pipe. 
With  the  above  property,  it  is  ensured  that  the  data  is  always  updated.  The 
main  drawback  in  the  use  of  pipes  is  that  they  can  be  used  for  communication 
between  only  two  processes,  one  to  write  and  the  other  to  read. 

The  purpose  of  using  priority  driven,  preemptive  scheduling  is  to  break  the 
execution  of  a  lower  priority  process  when  a  higher  priority  process  is  ready  to  run. 
If,  at  the  same  time,  a  synchronization  primitive  like  semaphores  is  used  to  avoid  race 
conditions,  the  following  problem  can  occur.  Consider  two  processes,  P\  and  P *2  with 
periods  T\  >  T*,  that  access  the  same  shared  data.  In  rate  monotonic  assignment,  P\ 
has  a  higher  priority  than  Pj.  Suppose  that  P2  first  accesses  that  data  and  locks  the 
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semaphore  that  controls  the  access.  If,  at  that  time,  Pi  starts  execution,  it  will  find  the 
semaphore  locked  and  will  have  to  wait  for  P2  to  finish  its  critical  section.  However, 
that  delay  may  be  longer  than  the  critical  section  of  P2  itself  if  P2  is  preempted  by  a 
third  intermediate  priority  process.  This  may  lead  to  uncontrollable  blocking. 

Such  blocking  of  a  higher  priority  process  by  a  lower  priority  one,  for  an  un¬ 
predictable  period  of  time,  is  called  priority  inversion.  The  easiest  solution  to  this 
problem  is  not  to  allow  a  process  to  be  preempted  at  the  time  it  is  executing  its 
critical  section.  However,  this  solution  creates  unnecessary  blocking  of  processes  not 
using  that  shared  data  and  is  appropriate  only  for  very  short  critical  sections.  In 
order  to  avoid  priority  inversion,  better  solutions,  like  the  priority  inheritance  pro¬ 
tocol  [Ref.  SRL91],  priority  ceiling  protocol  [Ref.  SRL91]  and  stack-based  resource 
allocation  [Ref.  Ba90]  have  been  proposed  in  the  literature.  Each  one  of  the  above 
has  a  different  way  of  reducing  the  timing  constraints  that  created  from  the  synchro¬ 
nization.  In  the  next  section,  we  shall  discuss  some  commonly  used  synchronization 
protocols. 

C.  TECHNIQUES  OF  REAL-TIME  SYNCHRONIZATION 

1.  Two  Phase  Locking  Protocol 

An  approach  to  achieve  the  required  synchronization  and  data  consistency 
between  the  tasks  is  the  two-phase  locking  protocol.  This  protocol,  as  implied  by 
its  name,  accesses  the  shared  data  or  resources  in  two  phases.  In  the  first  phase,  a 
task  tries  to  lock  all  the  synchronization  primitives  for  the  data  it  needs  to  update  or 
read.  If  it  succeeds  in  the  first  phase,  the  task  proceeds  to  the  second  phase,  where 
it  uses  the  data  and,  at  the  end,  releases  the  locks.  If  the  process  is  not  able  to 
lock  all  the  synchronization  primitives,  or  if  some  data  is  not  already  updated,  the 
process  either  stops  a  lower  priority  process  or  releases  all  the  locks  and  starts  from 
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the  beginning.  This  technique  is  not  desirable  when  a  high  processor  utilization  is  of 
great  importance.  Also,  the  locking  of  all  data  structures  that  are  going  to  be  used 
can  cause  priority  inversion  problems. 

2.  Priority  Inheritance  and  Priority  Ceiling  Protocol 

The  complete  definition  of  these  two  protocols  can  be  found  in  [Ref.  SRL91]. 
We  briefly  describe  them  here.  The  idea  upon  which  the  priority  inheritance  protocol 
is  based  is  that  when  a  process  with  low  priority  blocks  the  execution  of  a  higher 
priority  one,  it  inherits  the  highest  priority  of  all  the  processes  it  blocks  for  the  exe¬ 
cution  of  its  critical  section.  This  enables  the  low  priority  job  to  finish  its  execution 
without  the  possibility  of  being  preempted  from  an  intermediate  priority  job.  Under 
this  protocol,  although  data  consistency  is  achieved,  the  problems  of  deadlock  and 
chained  blocking  have  not  been  avoided  [Ref.  SRL91].  Chained  blocking  is  caused 
when  a  process  has  to  wait  for  more  than  one  lower  priority  process  to  unlock  the 
synchronization  primitive  being  used. 

In  the  priority  ceiling  protocol,  the  same  idea  as  in  priority  inheritance  is 
used.  However,  it  guarantees  that,  if  a  job  is  preempted  in  its  critical  section,  the  new 
job  will  execute  at  a  priority  higher  than  that  of  all  the  preempted  critical  sections. 
This  is  realized  by  assigning  a  priority  ceiling  to  each  semaphore,  which  is  equal  to 
the  highest  priority  of  a  task  that  may  use  that  semaphore.  A  job  is  allowed  to 
start  the  execution  of  a  new  critical  section  only  if  it  has  a  priority  higher  than  all 
the  priority  ceilings  for  all  the  semaphores  locked  by  jobs  other  than  itself.  In  this 
protocol,  unlike  the  priority  inheritance  protocol,  deadlocks  and  chained  blocking  are 
avoided,  but  a  new  kind  of  blocking,  called  the  ceiling  blocking,  is  present.  Also, 
the  priority  ceiling  protocol  creates  unnecessary  blocking  in  processes  that  are  never 
going  to  use  a  specific  semaphore.  This  happens  because  priorities  are  assigned  to 
semaphores  assuming  that  all  processes  are  dependent  on  each  other. 
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3.  Data-flow  Synchronization 

In  many  real-time  applications  like  the  AUV-II,  where  the  periods  of  the 
processes  and  the  synchronization  requirements  are  known  in  advance,  it  is  not  re¬ 
quired  to  use  a  complicated  protocol,  like  the  priority  ceiling  protocol,  to  implement 
synchronization.  This  reduces  the  size  of  the  application  scheduler,  since  there  is 
no  need  for  the  extra  lists  to  hold  the  different  priorities  of  the  semaphores,  the 
semaphores  that  are  locked,  etc.  Also,  it  reduces  the  computation  time  required 
to  select  the  next  process  to  run,  since  the  scheduler  has  to  select  only  from  those 
processes  that  have  received  the  updated  data. 

In  data-flow  scheduling,  synchronization  can  be  achieved  easily  using  sig¬ 
nals  between  processes.  The  signals  can  contain  the  data  to  be  transferred.  A  process 
is  ready  to  start  execution  only  if  it  has  received  data  from  all  the  preceding  pro¬ 
cesses  that  have  completed  execution.  A  process,  when  it  completes,  sends  signal  to 
its  succeeding  processes.  Until  all  such  signals  are  received,  a  process  does  not  start 
execution,  thus  ensuring  consistency  of  data  and  mutual  exclusion. 

D.  EFFECT  OF  SYNCHRONIZATION  ON  SCHEDULABILITY 

The  application  of  the  two  phase  locking  protocol  is  limited  in  real-time  appli¬ 
cations.  It  has  low’  processor  utilization  because  a  process  has  to  be  terminated  in 
the  middle  of  its  execution  when  a  resource  is  not  available  or  when  a  process  with 
higher  priority  needs  the  same  resource.  Also,  under  these  conditions,  the  application 
behavior  cannot  be  predicted  correctly  since  the  result  is  based  on  the  chance  that 
the  resources  will  be  available. 

For  the  priority  ceiling  and  the  priority  inheritance  protocols,  the  following 
corollary  has  been  proved  in  [Ref.  SRL91]. 
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A  set  of  n  periodic  tasks  using  the  priority  ceiling  protocol  can  be  scheduled 
by  the  rate  monotonic  algorithm  if  the  following  condition  is  satisfied: 
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where  u  is  the  utilization  factor,  C,  is  the  execution  time,  7,  the  period 
and  B,  is  the  worst  timing  blocking  of  the  i  process. 


Also,  Equation  (2.2),  which  enables  a  larger  upper  bound  of  the  utilization,  gets 
a  new  form  as  below  [Ref.  SRL91]. 

A  set  of  n  periodic  tasks  using  the  priority  ceiling  protocol  can  be  scheduled 
by  the  rate  monotonic  for  all  task  phasing  if: 
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where  R,  —  {{kj)\\  <  k  <  i,  l  =  1, ...,  [^-J },  Ci  the  execution  time,  7,  the 
period,  B,  the  worst  timing  blocking  of  the  i  process,  and  Uj  the  process 
utilization. 


It  can  be  derived  from  the  above  two  modified  theorems  that  the  processor  utilization 
is  changed  as  if  one  new  process  is  included  with  period  equal  to  the  worst  case 
blocking. 

The  expected  schedulability  of  the  data-flow  scheduling  combined  with  the  rate 
monotonic  algorithm  is  almost  the  same  as  the  one  provided  for  the  rate  monotonic 
algorithm.  The  only  difference  is  that  each  independent  set  of  tasks  is  treated  as 
one  task.  In  that  case,  since  the  number  of  tasks,  n,  in  Equations  (2.1)  and  (2.3) 
is  reduced,  the  upper  bound  of  processor  utilization  is  increased.  As  an  example, 
consider  the  seven  processes  of  Fig.  2.1.  According  to  Equation  (2.1),  the  upper 
bound  on  processor  utilization  is  expected  to  be  less  than  or  equal  to  7(2^  —  1)  =  0.73. 
However,  since  there  are  only  two  independent  sets  of  tasks,  the  processor  utilization 
is  expected  to  be  less  than  or  equal  to  2(2^  —  1)  =  0.83.  Since,  in  each  independent 
set,  the  processes  satisfy  the  condition  ^p  —  [3pJ  =  0  (fractional  part  of  ^p  =  0)  for 
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i  =  1.2 —  1.  This  means  that  processes  all  have  the  same  basic  period  or  an 
integer  multiple  of  that  basic  period.  According  to  [Ref.  LL73],  the  utilization  bound 
can  further  increase  to  1.0  when  no  aperiodic  processes  are  included  in  the  process 
set. 
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III.  SCHEDULING  AND  SYNCHRONIZATION 

FOR  AUV-II 


At  present,  the  AUV-II  scheduler  uses  the  rate  monotonic  algorithm,  appropri¬ 
ately  modified  to  work  on  the  OS-9  operating  system.  It  can  schedule  only  periodic 
processes  and  it  does  not  provide  any  synchronization  between  the  processes.  The 
scheduler  first  calculates  the  priorities  that  will  be  assigned  to  the  processes  according 
to  the  rate  monotonic  algorithm.  The  priorities  are  assigned  with  esufficient  spacing 
so  that  aging,  described  later,  will  not  have  any  effect.  The  process  set  is  then  an¬ 
alyzed  for  schedulability  according  to  Equation  (2.2).  If  the  set  is  schedulable,  the 
scheduler  forks  all  the  processes.  The  scheduler  has  an  array  which  keeps  the  next 
time  at  which  each  process  will  be  ready  to  start  execution.  By  following  these  re¬ 
quirements  in  an  infinite  loop,  the  scheduler  is  able  to  send  wake-up  signals  to  the 
processes  and  move  them  from  the  sleeping  queue  to  the  active  queue.  The  above 
loop  of  sending  wake-up  signals  instead  of  creating  and  killing  the  process  every  time 
was  selected  since  it  does  not  waste  computing  time  in  the  process  initialization  every 
time  it  is  executed.  This  real-time  scheduling  mechanism  needs  to  be  augmented  to 
incorporate  process  synchronization  and  aperiodic  processes.  This  chapter  describes 
how  this  is  done  by  using  PIPES  for  data-flow  synchronization  on  OS-9. 

A.  OS-9  SUPPORT  FOR  SCHEDULING  AND  SYNCHRONIZATION 

OS-9  is  an  operating  system  designed  to  support  real-time  applications.  It  has 
its  own  scheduler  with  two  main  queues  -  one  with  the  active  processes  and  the  other 
with  the  sleeping  processes  [Ref.  DiSSj.  When  a  process  is  forked,  it  is  placed  in  the 
active  queue  according  to  the  assigned  priority.  The  priorities  can  take  values  from  1 
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to  65,556.  A  process  is  placed  in  the  sleeping  queue  if  there  is  a  pause  ()  command 
in  its  source  code  or  if  it  is  waiting  for  I/O. 

The  OS-9  scheduler  finds  out  the  current  process  at  regular  intervals.  This  is 
the  process  at  the  top  of  the  active  queue  and  is  the  process  that  runs  next.  The 
regular  interval  is  called  a  tick  and  lasts  10  msec  on  the  system  being  used. 

The  main  steps  in  the  OS-9  scheduler  are  the  following: 

•  It  checks  for  sleeping  processes  that  are  ready  to  move  in  the  active  queue. 

•  It  checks  the  current  process  and  the  active  queue  to  find  out  which  one  has  the 
highest  priority  to  become  the  next  current  process. 

•  It  starts  the  execution  of  the  current  process. 

One  of  the  most  interesting  characteristics  of  the  OS-9  scheduler  is  aging.  With 
aging,  priorities  of  the  tasks  in  the  active  queue  are  increased  by  one  at  every  tick. 
This  characteristic  has  been  included  in  the  OS-9  scheduler  to  provide  fairness,  but  it 
causes  problems  when  RMS  is  attempted  on  top  of  OS-9.  The  priorities  of  processes 
must  follow  the  order  dictated  by  RMS,  but  they  must  be  sufficiently  separated  to 
make  aging  ineffective. 

Synchronization  can  be  achieved  in  OS-9  by  using  PIPES  and  Events.  There 
are  two  kinds  of  pipes  -  un-named  and  named.  The  main  difference  between  them  is 
that  a  process  cannot  write  to  an  unnamed  pipe  if  the  reader  is  not  ready  to  receive 
the  information.  Un-named  pipes  are  mainly  used  by  the  OS-9  shell.  Events  and 
pipes  are  supported  with  the  C  language  calls.  The  most  useful  ones  are  described  in 
Fig.  3.1  and  Fig.  3.2  respectively  [Ref.  GES90]. 

B.  IMPLEMENTATION  OF  DATA-FLOW  SYNCHRONIZATION 

The  new  run-time  scheduler  is  highly  dependent  on  the  synchronization  primi¬ 
tive  that  has  been  selected.  Both,  events  and  pipes,  are  primitives  which  can  be  used 
to  implement  synchronization  between  the  processes  of  AUV-II.  Since  events  require 
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Call 

Meaning 

_ev_creat 

_ev_link 

_ev_unlink 

_ev_vait 

_ev_signal 

_ev_read 

_ev_set 

Create  an  event  structure 

Increment  event  count 

Decreament  event  count 

Process  waits  until  Event  in  boundaries 
Increment  the  event  variable 

Reads  the  event  variable 

Sets  the  event  variable 

Figure  3.1:  Calls  associated  with  events. 


Cali 

Meaning 

_GC_Rdy 

_GC_Size 

closeO 

create () 

open() 

read() 

readlnO 

write() 

vritelnO 

Tests  whether  data  are  ready  in  buffer 
Returns  the  size  of  the  pipe  buffer 
Close  an  open  path 

Creates  a  new  pipe 

Opens  an  existing  path 

Reads  bytes  from  path 

Reads  one  line  from  path 

Writes  bytes  to  path 

Writes  one  line  to  path 

Figure  3.2:  Useful  calls  associated  with  pipes. 
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a  more  complicated  program  and  offer  functionality  not  required  in  AUV-II,  use  of 
pipes  was  selected.  Selection  of  the  appropriate  primitive  was  based  on  the  following 
considerations: 

•  The  critical  section  in  the  communication  between  the  processes  must  be  small 
and  consist  only  of  writing  and  reading  some  data. 

•  Events  require  construction  of  the  data  structure  to  hold  the  communication 
data. 

•  For  each  data  structure,  two  events  are  needed;  one  implements  the  mutual 
exclusion  in  the  use  of  the  data  structure  and  the  other  guarantees  the  data 
consistency. 

•  The  output  of  one  process  is  used  by  more  than  one  processes  only  in  one  case. 

All  the  above  observations  strengthen  our  decision  to  select  pipes  as  the  right  syn¬ 
chronization  primitive  for  the  AUV-II. 

By  selecting  pipes  as  the  synchronization  primitive,  some  major  modification 
had  to  be  done  in  the  run-time  scheduler,  developed  in  [Ref.  Le91],  that  changed 
completely  the  way  the  scheduler  worked. 

After  the  communication  via  pipes  was  included  in  the  tasks,  each  task  could 
wait  for  a  signal  from  the  run-time  scheduler  each  time  it  starts  execution  and  then  it 
could  wait  for  some  output  to  be  placed  in  the  pipes  that  it  reads.  This  could  cause 
a  process  to  stop  execution  at  least  twice.  Also,  as  in  Fig.  3.3,  if  the  process  has  not 
finished  the  execution  at  the  time  that  the  vake_up()  signal  is  sent,  the  processes 
misses  the  next  execution. 

The  solution  to  the  above  problem  is  given  in  Fig.  3.4.  This  solution  discards 
the  pause  ()  at  the  end  of  each  cycle  in  the  called  process  and  the  part  of  the  run-time 
scheduler  that  sends  the  wake.upO  signal.  Thus,  the  process  now  waits  only  for  the 
data  to  be  in  the  pipe. 

The  next  step  creates  periodicity  in  the  set  of  processes.  This  is  done  by  an 
extra  process  created  with  only  the  purpose  of  writing  a  dummy  message  on  a  pipe  as 
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Figure  3.3:  Missed  execution  due  to  not  waiting  in  a  pause. 
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Figure  3.4:  Correct  number  of  executions. 
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Period 

Figure  3.5:  No  periodic  execution  in  a  set  of  two  processes. 

in  Fig.  2.1.  The  dummy  message  is  read  from  the  process  with  the  highest  frequency 
in  the  set.  The  timing  process  code  is  similar  to  the  called  processes  code,  outlined 
in  Appendix  C. 

This  scheme  of  synchronization  has  the  advantage  that,  in  a  temporary  processor 
overload,  the  dummy  messages  will  be  accumulated  in  the  pipe.  So,  after  the  overload, 
the  processor  will  execute  all  the  processes  for  the  required  number  of  times  without 
missing  any  of  them.  Thus,  the  average  processor  utilization  can  be  close  to  1.0. 

The  above  data-flow  scheduling  cannot  guarantee  the  user  that  each  process 
will  run  at  exact  periodic  intervals.  This  is  because  of  the  required  communication 
between  processes  and  it  is  more  likely  to  happen  if  a  process  depends  on  a  process 
with  lower  frequency.  For  example,  in  Fig.  3.5,  the  process  Pi  that  has  a  period  of  20 
ticks,  over  an  interval  of  20  ticks,  releases  two  sets  of  information.  This  information 
is  used  by  process  P2  that  has  a  period  of  10  ticks  over  two  executions.  As  a  result, 
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P2  is  executed  twice  in  the  second  10  ticks  interval  and  is  not  executed  in  the  first 
10  ticks. 

What  the  scheduler  can  ensure  in  the  above  case  is  that,  at  time  equal  to  the 
least  common  multiplier  (LCM)  of  all  the  processes  periods,  each  process  z  will  execute 
LCM/T;  times.  For  the  above  example,  LCM  =  20  ticks;  so  PI  will  execute  10/20  = 
1  times  and  P2  will  execute  20/10  =  2  times  over  an  interval  of  20  ticks.  If  the  above 
condition  is  acceptable,  this  scheduling  scheme  is  better  than  the  old  one  because  the 
most  likely  result  with  the  old  algorithm  under  a  high  processor  utilization  is  that  P2 
would  miss  a  deadline. 

The  aperiodic  processes  can  also  be  integrated  with  the  above  scheme  of  schedul¬ 
ing.  One  difference  between  them  and  the  periodic  ones  is  the  trigger  that  will  cause 
the  start  of  the  execution.  For  the  periodic  ones,  the  trigger  is  the  timing  process. 
For  the  aperiodic  ones,  it  is  an  external  event  that  will  happen  and  cause  some  data 
to  be  written  in  the  pipe,  which  the  aperiodic  process  is  waiting  to  read.  For  example, 
in  the  AUV-II,  the  task  that  is  processing  the  sonar  data,  if  it  decides  that  there  is 
an  obstacle,  will  write  in  the  pipe  obstacle  alert  and  the  process  avoid  obstacle  will 
start  execution. 

Another  difference  in  incorporating  aperiodic  processes  with  periodic  ones  is 
the  way  the  priorities  are  assigned.  An  array  is  created  for  the  periodic  processes. 
The  first  process  in  that  array  is  the  one  with  the  smallest  period,  and  therefore,  the 
highest  priority.  The  last  one  is  the  one  with  the  largest  period,  and  therefore,  the 
lowest  priority  [Ref.  Le91].  For  the  aperiodic  processes,  since  the  average  period  in 
which  those  processes  arrive  is  not  of  great  importance,  another  criterion  had  to  be 
found  according  to  which  they  will  be  placed  in  the  array  and  the  priorities  will  be 
assigned. 
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for  (  i=l  ;  i=#of  aperiodic  processes  ;  i=i+l) 

{ 

find  lowest  priority  for  combined  process (i) ; 
place  the  i  th  process  in  that  position; 
remove  the  i  process  from  the  list; 

> 


Figure  3.6:  Algorithm  to  assign  priorities  to  aperiodic  processes. 

One  approach  is  to  give  priorities  to  the  aperiodic  processes  that  are  either 
higher  or  lower  than  the  periodic  ones.  After  running  some  sets  of  tasks  with  such 
assignment,  it  was  found  that  some  aperiodic  processes  with  low  timing  requirements 
were  blocking  the  execution  of  periodic  processes  without  any  reason.  Also,  aperiodic 
processes  with  high  timing  requirements  were  blocked  from  periodic  ones  with  lower 
timing  requirements.  The  solution  is  an  algorithm  to  enable  an  aperiodic  process  to 
block  only  the  required  number  of  periodic  processes  in  order  to  achieve  the  expected 
response  time.  The  algorithm  that  has  been  used  is  shown  in  Fig.  3.6.  In  this 
algorithm,  the  term  combined  process  refers  to  a  hypothetical  process  with  response 
time  equal  to  the  minimum  response  time  of  all  the  aperiodic  processes  that  have 
equal  or  higher  laxity.  Its  execution  time  is  equal  to  the  sum  of  the  execution  times 
of  aperiodic  processes  with  equal  or  higher  laxity.  Laxity  is  defined  as  the  response 
time  minus  the  execution  time  of  a  process.  In  the  following  example,  an  application 
of  the  algorithm  in  Fig.  3.6  is  demonstrated. 

Example:  In  this  example,  all  the  times  are  in  ticks.  Consider  four  periodic 
processes  PI,  P2,  P3,  and  P4  with  execution  times  Ci=l,  C2= 3,  C3=l,  and  C4= 4. 
The  periods  are  7\=5,  72=10,  73=10,  and  7^=20  respectively.  Consider  two  aperiodic 
processes,  A.  and  A2,  with  execution  times,  0^1=10  and  Ca2=6,  average  interarrival 
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Exec. Time 
[tick] 

Resp.Time 

[tick] 

1 

PI 

T\  = 

5 

Cx  = 

1 

2 

Al 

Tm  = 

100 

Cai  = 

10 

Ra\  — 

20 

3 

P2 

t2  = 

10 

Ct  = 

3 

4 

A2 

TA2  = 

100 

Ca2  ~ 

6 

Ra2  = 

30 

5 

P3 
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10 
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1 

6 

P4 

t4  = 

20 

c<  = 

4 

Figure  3.7:  Order  in  which  priorities  will  be  assigned. 


periods,  Tyii=100  and  T42=100,  and  maximum  response  times,  J?^i=20  and  RA2=Z0. 
According  to  the  rate  monotonic  algorithm,  the  periodic  process  Pi  has  the  highest 
priority  and  P4  has  the  lowest.  The  priorities  to  be  assigned  to  the  aperiodic  processes 
are  determined  as  follows: 

•  Find  the  position  where  the  combined  aperiodic  process  for  Al,  which  has  re¬ 
sponse  time  f?coMi=20  and  execution  time  Cco mi =16,  meets  the  timing  re¬ 
quirements.  That  position  is  between  PI  and  P2,  because,  in  the  worst  case 
that  Pi,  P2,  and  Al  start  together  at  time  interval  Rcomi  =20,  PI  needs  4,  P2 
needs  6,  and  AIcom  needs  16  ticks. 

•  Place  Al  between  Pi  and  P2. 

•  Find  the  position  where  the  combined  aperiodic  process  for  A2,  which  is  only 
A2,  meets  its  timing  requirements.  This  process  can  be  placed  between  P2  and 
P3  for  the  same  reason. 

•  Place  Al  between  P2  and  P3. 


Figure  3.7  displays  the  final  list  according  to  which  the  priorities  are  assigned. 
If  the  combined  aperiodic  process  had  not  been  used,  Al  would  have  been  placed 
between  P2  and  P3.  Also,  A2  would  have  been  placed  between  P2  and  Al.  The 
order,  in  that  case,  would  have  been  the  one  in  Fig.  3.8.  This  order  is  not  correct 
because  A2  has  a  priority  higher  than  Al.  Therefore,  Al  is  not  able  to  meet  its 
response  time  if  A2  is  being  executed. 
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Figure  3.8:  Priority  assignment  not  using  combined  process  concept. 

The  called  processes  have  the  general  form  of  Fig.  3.9.  The  first  modifica¬ 
tion  made  in  the  called  processes  was  to  include  the  open()  statment  in  the  ini¬ 
tialization  commands  so  the  process  can  have  access  to  the  pipes.  Also,  a  call  to 
signal_to_run— time_scheduler()  is  included  to  signal  the  scheduler  that  initial¬ 
ization  is  completed.  The  next  modification  was  to  include  the  read()  part  in  the 
repeated  commands.  The  read  commands  are  different  if  the  process  tries  to  read  the 
output  of  a  periodic  process  as  against  that  of  an  aperiodic  process.  If  the  process 
reads  from  a  periodic  one,  it  directly  tries  to  read  the  pipe.  So,  it  is  suspended  until 
the  information  is  ready.  If,  on  the  other  hand,  it  reads  from  an  aperiodic  process, 
the  read()  is  included  in  an  if  ()  statement  that  first  checks  the  pipe  to  see  if  there 
is  any  information  ready,  as  in: 

if(  information  at  pipe  )  then(  read(pipe)  ); 

This  is  done  because  it  is  not  desirable  to  block  the  execution  of  a  process  for  data 
that  is  not  always  expected  to  be  there.  Finally,  the  write  ()  statement  is  included 
where  the  process  sends  the  output  to  other  processes. 

Since  pipes  are  files,  the  data  transferred  has  to  be  characters.  However,  it 
can  be  formatted  in  any  desired  order.  At  the  receiver,  it  can  be  modified,  without 
restrictions,  to  any  kind  of  variables  like  integers,  floating  point  numbers,  or  strings. 
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mainO 

{ 

initialization  commands; 


open(pipes) ; 

vake_up_mn-time_scheduler  () ; 
pause() ; 
while (TRUE) { 

read (pipes) ; 
repeated  commands; 


write(pipes) ; 

> 

close(pipes) ; 

vake_up_run-time_scheduler() ; 
exit() ; 


Figure  3.9:  General  structure  of  a  called  process. 
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MAIN  MENU 


1  =  ADD  NEW  SET  DF  TASKS 

2  *  VIEW  TASKS 

3  =  CHANGE  PARAMETERS 

4  *  MAKE  SCHEDULABILITY  ANALYSIS 

5  =  RUN  TASKS  SET 

6  *  EXIT 


Figure  3.10:  Main  menu  for  the  run-time  software. 

For  the  purpose  of  collecting  the  timing  data,  a  function  that  takes  the  time 
stamp  has  been  included  at  the  beginning  and  the  end  of  the  while  ()  statment.  Also, 
a  delay  loop  has  been  included  instead  of  the  repeated  commands  with  variable  time 
length.  That  delay  is  now  an  input  variable  from  the  run-time  scheduler.  The  source 
code  of  one  of  the  dummy  processes  that  was  used  is  outlined  in  Appendix  C. 

C.  USER  INTERFACE 

The  run-time  software  has  been  completely  changed  in  order  to  separate  the 
initialization,  the  schedulability  analysis,  and  the  task  execution  part.  The  code  of 
the  run-time  software  is  outlined  in  Appendix  A  and  the  code  of  the  functions  that 
are  used  by  the  run-time  software  is  outlined  in  Appendix  B.  When  the  program 
starts,  a  menu  appears  on  the  screen  similar  to  the  one  in  Fig.  3.10. 

By  selecting  ADD  NEW  SET  OF  TASKS,  the  program  first  asks  the  user  if  he/she 
desires  to  insert  the  information  by  using  the  keyboard  or  by  having  the  program 
read  a  file.  In  the  latter  case,  the  user  has  to  specify  the  name  of  the  file.  If  the 
user  decides  to  use  the  keyboard,  the  program  first  asks  how  many  periodic  tasks 
will  be  executed.  Then,  for  each  one  of  these,  the  user  has  to  supply  the  name,  the 
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-  PERIODIC  PROCESSES  - 

NAME  PERIOD  EXECUTION  TIME 

I  PI  I  5  I  1  I 

I  P2  I  10  I  3  I 

I  P3  I  10  |  1  I 

I  P4  I  20  |  4  I 


. - .  APERIODIC  PROCESSES  . . . 

NAME  PERIOD  EXECUTION  TIME  RESPONCE  TIME 

I  A1  I  100  I  10  I  20  | 

I  A2  I  100  I  6  I  30  | 


Figure  3.11:  Display  on  the  screen  of  the  attributes. 

period  and  the  execution  time.  After  the  user  has  finished  with  the  periodic  processes, 
the  program  asks  for  the  number  of  aperiodic  processes.  For  each  aperiodic  process, 
the  user  has  to  specify  the  name,  the  average  period,  the  execution  time,  and  the 
maximum  response  time.  All  the  above  timing  attributes  have  to  be  in  ticks.  When 
all  the  attributes  have  been  inserted,  the  program  sorts  the  periodic  and  aperiodic 
processes.  The  periodic  processes  are  sorted  in  the  increasing  order  of  periods.  The 
sorting  for  aperiodic  processes  is  in  the  increasing  order  of  laxity.  The  data-flow 
diagram  that  the  process  set  implements  cannot  be  changed  by  using  the  scheduler  at 
this  time.  If  the  user  wants  to  change  it,  he/she  has  to  change  the  pipes  .c  program 
and  the  called  processes. 

By  selecting  VIEW  TASKS,  an  output  similar  to  the  one  in  Fig.  3.11  appears 
on  the  screen.  By  selecting  CHANGE  PARAMETERS,  the  program  first  asks  the  user  to 
specify  if  he/she  wants  to  change  a  periodic  or  an  aperiodic  process.  Then  the  user, 
following  the  on-screen  instructions,  can  change  the  name  and  attributes  of  a  process. 
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By  selecting  MAKE  SCHEDULABILITY  ANALYSIS,  the  run-time  software  executes 
two  major  objectives.  Firstly,  it  makes  the  schedulability  analysis  for  both  periodic 
and  aperiodic  processes,  and  at  the  same  time,  fills  an  array  with  the  names  of  the 
processes  in  the  order  discussed  in  Section  B.  Secondly,  it  creates  an  array  with  entries 
of  the  priorities  that  each  process  receives  if  the  user  later  decides  to  run  the  set  of 
tasks. 

The  schedulability  analysis  for  the  periodic  processes  is  almost  the  same  as  the 
one  explained  by  B  Leatherman  in  the  [Ref.  Le91]  and  the  software  mainly  consists 
of  functions  that  are  part  of  the  rate_mono  program  in  the  same  reference.  If  the 
periodic  set  is  schedulable,  the  schedulability  analysis  program  displays  the  remaining 
processor  utilization  that  may  be  used  for  aperiodic  processes.  If  the  periodic  set  is 
not  schedulable,  it  displays  the  processor  utilization  and  returns  to  the  main  menu. 

Schedulability  analysis  of  the  aperiodic  processes  is  done  in  two  steps.  First,  the 
program  checks  if  the  processor  utilization  that  remains  from  the  periodic  set  of  tasks 
is  sufficient  for  the  aperiodic  processes.  If  it  is,  the  following  message  is  displayed: 

Total  set  SCHEDULABLE 

If  it  is  not,  the  program  displays  the  following  message  and  exits  the  schedulability 
analysis  function: 

Total  set  NOT  schedulable 

In  case  schedulable  set,  the  software  proceeds  to  the  second  step.  Starting  with  the 
aperiodic  process  that  has  lowest  timing  requirements,  it  checks  if  the  laxity  of  that 
process  is  larger  than  the  sum  of  all  other  aperiodic  execution  times.  If  it  is  not, 
the  process  may  not  meet  its  response  time  in  case  that  all  aperiodic  processes  start 
together.  In  that  case,  the  first  message  is  augmented  as: 

But  response  time  of  "A2"  process  may  NOT  be  achieved 
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By  selecting  RUN  TASK  SET,  the  run-time  software  starts  execution  of  the  set  of 
tasks.  This  part  is  extremely  dependent  on  the  synchronization  primitives  that  have 
been  selected.  First,  it  calls  a  function  that  forks  the  process  pipes. c  which  creates 
all  the  pipes.  This  process  remains  active  until  all  the  tasks  finish  their  execution; 
otherwise,  if  that  process  were  allowed  to  finish  execution,  all  the  pipes  would  close. 
The  same  function  also  forks  the  process  start  .c  that  supplies  the  information  that 
the  set  of  tasks  needs  to  start  execution.  The  process  start .  c,  at  present,  just  sends 
the  word  “start”  in  a  designated  pipe.  It  can  be  easily  modified  to  ask  the  user  for  the 
required  initialization  information.  The  code  for  pipes. c  is  outlined  in  Appendix  D. 

Following  this,  the  scheduler  forks  all  the  processes  one  by  one.  It  stops  after 
forking  each  process  until  the  forked  process  finishes  the  initialization  part.  This  is 
necessary  because  the  initialization  part  of  each  process  is  now  longer  than  its  average 
execution  time.  The  part  of  the  scheduler  that  sends  the  wake-up  signals  has  been 
modified  as  has  been  explained  in  Section  B. 

After  the  run-time  scheduler  has  forked  all  the  processes,  it  waits  in  a  loop  with 
pause ()  till  all  the  forked  processes  have  completed  execution.  This  ensures  that  the 
scheduler  does  not  exit  before  all  the  forked  processes  have  finished  execution.  Note 
that,  in  OS-9,  a  child  process  cannot  ex;st  without  the  parent  process. 

Finally,  by  selecting  EXIT,  the  program  provides  to  the  user  the  option  to  save 
the  task  set  names  with  all  the  attributes  into  a  file  for  later  use. 

D.  PERFORMANCE  OF  PIPE-BASED  SYNCHRONIZATION 

As  described  in  the  AUV-II  data-flow  diagram  in  Chapter  I,  it  is  likely  to  have 
eight  processes.  Six  are  periodic  and  two  are  aperiodic.  The  periodic  processes 
are  designed  to  run  at  10Hz.  By  using  the  rate  monotonic  algorithm,  when  all  the 
processes  are  independent,  the  expected  processor  utilization  is  equal  to  1.0  according 
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Figure  3.12:  Process  set  with  different  execution  frequencies  for  Experi¬ 
ment  1. 

to  [Ref.  LL73].  When  processes  are  running  at  different  frequencies,  the  results  are 
according  to  [Ref.  Le91],  with  the  difference  that  each  independent  set  of  tasks  is 
treated  as  one  process.  We  are  interested  in  what  the  maximum  processor  utilization 
will  be  when  pipe-based  synchronization  is  included  for  the  following  situations: 

•  Only  periodic  processes  are  present. 

•  Both,  periodic  and  aperiodic  processes,  are  present. 

Also  for  the  second  situation,  it  is  of  interest  to  verify  that  the  response  time  of  the 
aperiodic  processes  is  acceptable. 

E.  EXPERIMENTAL  RESULTS 

The  first  set  up  used  to  verify  the  scheduler  is  one  with  four  periodic  processes. 
In  Fig.  3.12,  the  attributes  of  those  processes  axe  displayed.  Figure  3.13  displays  the 
data-flow  diagram  for  these  processes.  The  number  on  the  arcs  describes  how  many 
items  are  produced  and  how  many  are  consumed  each  time  a  process  is  executed. 
The  above  set  yields  a  processor  utilization  very  close  to  1.0.  The  timing  diagram  of 
the  process  execution  is  displayed  in  Fig.  3.14.  After  the  first  complete  execution,  the 
set  is  periodic  with  period  40  ticks,  which  is  the  LCM  of  all  the  periods.  Increasing 
the  load  delays  the  first  execution  of  P4. 
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The  second  set  used  to  verify  the  scheduler  was  one  with  periodic  and  aperiodic 
processes.  This  set  uses  the  data-flow  diagram  in  Fig.  3.15  and  mimics  the  AUV 
requirements.  The  process  set  and  the  attributes  that  were  used  are  shown  in  Fig  3.16. 


The  timing  information  obtained  from  this  execution  verified  the  following: 

•  The  aperiodic  processes  meet  all  their  timing  requirements,  if  their  interarrival 
time  is  the  expected  one. 

•  The  processor  utilization  can  be  as  high  as  1.0. 

•  The  periodicity  of  the  periodic  processes,  although  disrupted  by  the  arrival  of 
an  aperiodic  process,  is  restored  eventually  after  a  few  cycles  of  execution. 

•  All  the  worst  case  conditions  can  be  predicted  in  advance. 
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Figure  3.14:  Timing  diagram  for  experiment  1. 
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Figure  3.16:  Order  in  which  priorities  are  assigned. 


IV.  FRAMEWORK  FOR  A  GRAPHICAL 
USER  INTERFACE 


A.  GRAPHICAL  USER  INTERFACE  REQUIREMENTS 
1.  Current  Operation 

The  AUV-II  scheduler,  as  described  in  Chapter  III,  performs  schedulability 
analysis  for  periodic  and  aperiodic  processes  before  run-time  and  performs  scheduling 
and  synchronization  at  run-time.  However,  the  availability  of  a  schedulability  analyzer 
and  a  run-time  scheduler  does  not  make  the  cycle  of  real-time  software  development 
easy.  The  user  of  these  tools,  who  is  unlikely  to  be  an  expert  in  real-time  scheduling, 
must  find  them  easy  to  use.  Therefore,  there  is  a  need  for  a  Graphical  User  Interface 
(GUI)  capable  of  accomplishing  these  functions  in  an  easy  way.  The  current  user 
interface  communicates  with  the  user  by  asking  questions  and  receiving  appropriate 
answers. 

The  information  that  this  simple  interface  can  supply  to  the  user,  through 
the  main  menu,  is  the  display  of  the  last  selected  set  of  tasks  and  their  attributes. 
After  the  analysis  for  a  given  set  of  tasks  has  been  completed,  the  software  supplies 
to  the  user  the  processor  utilization  for  periodic  tasks,  prediction  of  whether  or  not 
the  periodic  set  is  schedulable,  total  processor  utilization,  prediction  of  whether  or 
not  the  total  set  is  schedulable,  prediction  of  aperiodic  processes  that  may  not  meet 
their  timing  requirements,  and  finally,  order  in  which  the  priorities  will  be  assigned. 
Also,  the  user  can  manually  find  the  time  intervals  at  which  each  process  is  executed 
by  reading  the  output  files  that  are  created  for  that  purpose  from  each  task. 

The  above  information  appears  on  the  screen  once,  stays  there  as  long  as 
the  user  wants  to  inspect  it,  and  then  disappears.  This  causes  difficulties  when  the 
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user  has  to  correlate  more  than  one  pieces  of  information  at  the  same  time.  The  only 
available  solution  to  this  problem  is  manual  tracking.  For  a  large  number  of  tasks, 
such  handling  of  information  is  difficult  and  error  prone.  This  condition  cannot  be 
improved  beyond  a  limit  because  the  user  interface  was  designed  in  the  old  fashion 
question-answer  process.  This  interface  is  also  limited  by  the  capabilities  of  the 
currently  used  display  hardware  which  is  a  simple  VT220  terminal. 

2.  Requirements 

Since  the  AUV-II  is  still  in  its  development  stage,  one  or  more  of  the 
following  scenarios  are  likely  to  occur: 

•  A  process  can  be  omitted  or  combined  with  other  processes.  New  processes  may 
be  required  for  the  vehicle  operation. 

•  For  any  task,  more  than  one  versions  may  be  written  to  implement  different 
algorithms.  This  will  force  the  user  to  select  from  a  collection  of  tasks  each 
time. 

•  More  than  one  scheduling  algorithm  may  be  implemented.  Currently,  the  user 
has  a  choice  of  selecting  the  scheduling  algorithm  created  in  [Ref.  Le91],  or  the 
one  proposed  in  Chapter  III,  or  the  OS-9  scheduler  without  any  enhancement. 

•  Process  attributes  may  be  change  because  of  modifications  in  the  programs. 

•  After  one  pass  of  the  schedulability  analysis,  the  user  may  need  to  change  task 
attributes  in  order  to  find  a  workable  combination  for  the  application. 

Also,  the  scheduling  scheme  that  has  been  proposed  can  be  used,  not  only  by  the 
AUV-II  project,  but  by  other  real-time  applications  also. 

Given  these  likely  scenarios  and  the  fact  that  a  replacement  of  the  current 
computer  by  a  portable  workstation  is  planned,  it  was  decided  that  a  Graphical  User 
Interface  (GUI)  would  make  the  AUV-II  software  development  process  much  simpler. 
Using  a  mouse  and  a  keyboard,  this  GUI  will  enable  the  user  to  perform  the  following 
tasks  easily: 

•  Select  a  real-time  application. 
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•  Select  a  scheduling  algorithm. 


•  Select  the  tasks  that  he/she  wants  to  use. 

•  Modify  the  attributes  of  a  task. 

•  Have  all  the  selected  tasks  displayed. 

•  Have  the  results  of  the  schedulability  analysis  displayed. 

GUI’s  are,  in  general,  difficult  to  implement  because  the  designer  has  to 
take  care  of  more  than  one  input  device  like  the  mouse  and  the  keyboard  at  the  same 
time.  This  implementation  is  somewhat  simplified  by  the  availability  of  standard 
software  packages  for  manipulating  the  display.  However,  the  designer  must  pick 
from  hundreds  of  procedures  in  every  package  in  order  to  achieve  his  goal.  One 
system  that  provides  the  necessary  tools  to  a  GUI  designer  is  the  X  window  system 
that  is  over  viewed  in  the  next  section. 

B.  X- WINDOW  SYSTEM 

The  X  Window  System  is  a  software  environment  which  is  used  for  engineering 
workstations  [Ref.  Jo89].  It  has  the  capabilities  to  control  the  displays  and  to  provide 
a  standard  environment  for  different  applications. 

The  X  environment  consists  of  layers  built  upon  the  base  window  system ,  as 
can  be  seen  in  Fig.  4.1  [Ref.  Jo89].  The  base  window  system  is  able  to  have  out¬ 
side  communication  by  using  the  X  network  protocol,  which  is  also  the  only  way  to 
communicate  with  it. 

Because  it  is  hard  to  use  the  network  protocol  directly,  there  is  a  low-level 
programming  interface  named  Xlib.  This  is  a  package  containing  subroutines  in  C 
language.  There  are  also  higher  level  toolkits  by  which  the  details  of  the  network 
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Figure  4.1:  X  software  environment. 


protocol  are  masked.  Xlib  provides  a  way  to  receive  for  different  inputs  in  the  appli¬ 
cation  programs,  such  as  inputs  by  pressing  keys  on  the  keyboard  or  by  moving  and 
pressing  the  mouse  buttons.  It  also  provides  tools  for  output  that  has  the  following 
capabilities. 

•  The  screen  can  be  organized  in  a  hierarchical  fashion  by  overlapping  windows, 
resizing  them,  moving  them,  and  putting  as  many  as  the  application  needs  on 
top  of  each  other. 

•  Each  drawing  is  bitmapped  and  corresponds  to  a  specific  address  on  the  specific 
window. 

•  High-quality  text  can  be  sent  to  the  screen. 

•  A  wide  variety  of  colors,  as  well  as  black  and  white  models,  can  be  used. 

•  Manipulation  of  different  images  is  possible. 

Since  Xlib  allows  the  designer  to  access  the  above  facilities,  it  provides  a  rich 
environment  for  building  user  interfaces.  As  low  level  environment,  it  allows  direct 
control  of  all  the  details  required  by  the  application.  For  these  reasons,  it  was  selected 
as  the  most  appropriate  tool  to  create  a  GUI  for  the  AUV-II. 
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As  has  been  mentioned  earlier,  the  way  that  the  application  communicates  with 
the  base  window  system,  and  vice  versa,  is  via  a  network  protocol.  The  fundamental 
elements  of  this  protocol  are  requests  and  events.  Requests  are  messages  that  originate 
from  the  application  and  events  are  messages  that  originate  from  the  workstation. 

The  request  messages  instruct  the  workstation  to  take  actions  required  by  the 
application  such  as,  opening  a  window,  changing  the  color,  displaying  some  context, 
etc.  On  the  other  hand,  event  messages  are  used  for  external  events  that  affect  the 
application,  such  as  a  movement  of  the  cursor,  a  keyboard  button  press,  a  press  of 
the  mouse,  etc.  How  the  application  interprets  all  these  events  is  determined  only  by 
the  designer  who  writes  the  appropriate  code  in  the  application  program. 

A  GUI  creates,  uses,  and  destroys  different  resources  in  the  course  of  its  op¬ 
eration.  These  resources  are  the  tools  that  make  the  user  interface  friendly.  The 

resources  that  were  used  in  this  design  are: 

•  Windows:  These  are  rectangular  areas  on  the  video  screen.  In  every  window,  the 
information  that  the  user  would  like  to  be  visible  is  specified.  These  windows 
may  overlap  one  another  according  to  the  user’s  input. 

•  Graphical  Contexts:  These  resources  are  used  to  specify  the  style,  size,  line  width 
for  the  text  that  the  user  wants  to  be  displayed,  foreground  and  background 
colors,  etc. 

•  Fonts:  These  resources  are  the  ones  that  control  the  character  text  that  are 
used,  like  shape,  size,  etc. 

•  Pixmaps:  These  resources  are  used  by  the  application  to  copy  information  be¬ 
tween  windows.  This  capability  is  very  helpful  since  all  the  selections,  correc¬ 
tions,  additions,  etc.,  may  not  take  place  on  the  main  window,  but  on  others 
that  may  open  according  to  the  user’s  will. 

•  Cursors:  With  these  resources,  the  cursor  shape  of  the  on-screen  pointer  can 
be  manipulated  which  the  user  can  move  around  by  moving  the  mouse. 

C.  GUI  IMPLEMENTATION 

By  using  Xlib,  a  GUI  consisting  of  a  matin  window  in  which  all  the  required 
information  is  displayed  and  some  pop-up  windows  that  could  be  used  for  different 
selections  and  modifications  was  created. 
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1.  Main  Window 


In  the  main  window,  as  can  be  seen  in  Fig.  4.2,  the  present  status  of  the 
process  set,  together  with  the  selection  buttons  and  the  output  of  the  schedulability 
analyzer,  is  displayed. 

At  the  top  of  the  window,  there  is  the  title  SCHEDULER  FOR:  followed 
by  the  object  to  be  analyzed.  This  reflects  that  the  GUI  can  be  used  in  applications 
other  than  the  AUY'-II.  The  present  status  of  the  tasks  is  displayed  in  the  two  windows 
described  below. 

•  PERIODIC  TASKS:  In  this  window,  the  user  can  observe  all  the  selected  pe¬ 
riodic  tasks,  their  execution  time,  and  their  period.  This  information  is  also 
needed  by  the  schedulability  analyzer. 

•  APERIODIC  TASKS:  In  this  window,  the  user  can  observe  the  selection  for  the 
aperiodic  tasks,  their  execution  time,  mean  period,  standard  deviation  from  the 
mean  period,  and  the  maximum  response  time  in  which  the  process  is  expected 
to  finish  execution. 


Output  of  the  schedulability  analyzer  is  displayed  in  two  windows  as  described  below. 

•  CPU  UTILIZATION:  It  contains  information  for  the  CPU  utilization  for  peri¬ 
odic  tasks,  aperiodic  tasks,  and  the  total  set  of  tasks. 

•  MISSED  DEADLINES:  In  this  window,  the  user  can  observe  if  the  deadline  of 
a  process  was  missed  and  which  process  missed  it. 

On  top  of  the  main  window  are  the  selection  buttons.  Any  of  them  is 
selected  by  placing  the  cursor  on  top  of  one  and  clicking  the  mouse.  The  use  of 
textual  buttons  was  preferred  instead  of  icons  because  it  is  very  difficult  to  have  a 
design  representing  the  required  meaning.  The  selection  buttons  are  the  following: 

•  SELECT  POLICY. 

•  SELECT  OBJECT. 

•  SELECT/ADD  TASKS. 
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SCHEDULER  FOR:  AUV II 
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Figure  4.3:  GUI  window  diagram. 


•  CHANGE  PARAMETERS. 

•  SCHEDULABILITY  ANALYSIS. 

•  RUN. 

•  QUIT. 

The  results  of  selecting  each  one  of  these  buttons  are  listed  in  the  next  section. 

2.  Pop-up  Windows 

The  first  four  buttons  open  the  pop-up  windows  and  the  following  three 
call  the  appropriate  function.  Figure  4.3  displays  how  the  user  can  move  around  the 
windows. 

By  selecting  the  button  SELECT  POLICY,  the  window  in  Fig.  4.4  opens 
on  top  of  the  main  one.  With  this,  the  user  can  select  the  scheduling  policy  that 
he/she  wants  to  use  in  order  to  execute  the  set  of  tasks  or  to  perform  schedulability 
analysis. 

By  selecting  the  button  SELECT  OBJECT,  a  window  similar  to  the  one 
in  Fig.  4.4  opens.  With  this  option,  the  user  can  select  the  object  for  which  this  user 
interface  will  be  used.  Also,  the  title  on  top  of  the  main  window  changes.  In  both  of 
the  above  windows,  the  different  options  are  read  from  a  file. 
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SCHEDULER  FOR:  AUV II 


Figure  4.4:  Select  policy  window. 
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By  selecting  the  button  SEL/ADD  TASKS,  the  window  in  Fig.  4.5  ap¬ 
pears.  This  window  consists  of  two  subwindows  -  one  for  periodic  tasks  and  the  other 
for  aperiodic  ones.  Since  it  is  possible  to  have  more  than  one  programs  for  each  task, 
the  user  can  select  the  ones  that  he/she  wants  to  use  for  each  experiment.  In  this 
window,  the  scroll  bars  can  be  used  to  change  the  selections,  the  keyboard  to  add 
new  ones,  and  the  mouse  to  either  change  the  default  ones.  The  mouse  can  also  be 
used  to  go  to  the  window  CHANGE  PARAMETERS  and  simultaneously  close  the 
present  one  or  to  quit  this  window  and  go  to  the  main  one. 

By  selecting  the  button  CHANGE  PARAMETERS,  the  window  in 
Fig.  4.6  appears.  It  is  the  one  that  the  can  be  used  to  give  the  tasks  attributes 
needed  by  the  schedulability  analyzer.  This  window  also  consists  of  two  subwindows 
-one  for  the  periodic  and  the  other  for  the  aperiodic  tasks. 

By  selecting  the  button  SCHEDULABILITY  ANALYZER,  according 
to  the  selected  policy  in  the  SELECT  POLICY  window,  the  software  calls  the  function 
that  implements  the  specified  schedulability  analysis  and  supplies  the  information  in 
the  windows  CPU  UTILIZATION  and  MISSED  DEADLINES. 

By  selecting  the  button  RUN,  the  software  calls  the  function  that  starts 
the  execution  of  the  selected  tasks. 

Finally,  the  button  QUIT  quits  the  scheduler  and  closes  the  main  window. 

D.  PROBLEMS  IN  THE  GUI  IMPLEMENTATION 

The  following  problems  arose  in  developing  the  GUI.  First,  at  the  time  of  the 
GUI  execution,  some  windows  did  not  appear  on  the  screen  or  sometimes  they  could 
not  receive  an  event  such  as  a  button  press.  This  was  due  to  an  excessive  number  of 
open  windows  that  were  created.  As  an  example,  in  Fig.  4.5,  the  window  that  displays 
the  periodic  tasks  consists  of  the  window  that  is  displayed,  a  larger  window  below  the 
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SCHEDULER  FOR:  AUV II 


Figure  4.6:  Change  parameters  window. 
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one  that  appears,  and  an  array  of  windows  in  which  each  window  element  displays 

the  attributes  of  one  task.  The  reason  for  having  a  large  window  is  to  provide  the 

user  with  the  ability  to  scroll  the  text  up  and  down.  The  reason  of  having  an  array 

of  windows,  one  for  each  task,  is  to  provide  the  capability  to  select  only  one  task  at 

a  time.  In  order  to  solve  this  problem,  more  interactive  communication  between  the 

application,  the  window7  manager,  and  the  memory  manager  is  needed. 

The  next  problem  was  the  use  of  the  keyboard  to  add  or  select  some  of  the  tasks’ 

attributes.  Unlike  a  simple  video  display  terminal  where  whatever  the  user  types  is 

displayed  on  the  terminal,  in  an  X  window  application,  when  the  user  presses  a  key, 

an  event  is  sent  to  a  specific  window.  It  is  then  up  to  the  application  to  interpret 

that  event.  For  modifying  task  attributes,  an  entire  editor  has  to  be  created. 

One  solution  to  most  of  the  above  problems  is  the  X  toolkits  whose  purpose 

is  to  simplify  the  GUI  programming.  One  X  toolkit  that  provides  all  the  required 

components  for  a  GUI  is  the  Athena  widget  set.  The  Athena  X  widgets  consist  of  a 

set  of  prebuilt  windows  with  special  characteristics  that  can  be  used  as  components 

to  create  a  GUI.  Some  of  those  widgets  are  menus,  dialogue  boxes,  scrollbars,  text 

widgets,  etc.  Our  experience  in  building  a  GUI  using  Xlib  is  aptly  summarized  by 

quoting  Mark  Langley  from  [Ref.  NO90,  page  37]: 

Window  systems  may  be  simple  to  use,  but  they  are  very  complex  to 
program.  The  first  thing  that  strikes  the  novice  X  programmer  is  how 
complicated  everything  is.  Learning  to  program  the  X  Window  System, 
even  with  the  help  of  the  X  Toolkit,  is  a  far  cry  from  learning  say,  the  C 
programming  language... 
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V.  CONCLUSIONS  AND  FUTURE 
DIRECTIONS 


This  chapter  summarizes  what  the  study  has  achieved  for  the  development  of 
the  AUV-II  real-time  software  and  provides  some  directions  for  further  research  and 
improvements. 

A.  CONCLUSIONS 

The  major  objectives  of  this  study,  as  have  been  specified  in  Chapter  I,  have 
been  accomplished.  A  scheme  capable  of  scheduling  both  periodic  and  aperiodic 
processes  has  been  created.  Periodic  processes  are  assigned  priorities  according  to 
the  rate  monotonic  scheduling.  Aperiodic  processes  are  assigned  priority  in  order 
to  achieve  the  expected  response  time,  and  at  the  same  time,  block  as  few  periodic 
processes  as  possible.  Thus,  the  scheduling  scheme  yields  a  high  processor  utilization 
and  handles  both  kinds  of  processes  smoothly  by  providing  the  required  frequency  in 
the  periodic  ones  and  the  expected  response  time  in  the  aperiodic  ones. 

The  synchronization  primitive  that  has  been  selected  is  OS-9  PIPE.  Its  use 
provides,  without  any  additional  programming,  both  mutual  exclusion  and  data  con¬ 
sistency.  Although  synchronization  conflicts  with  scheduling,  this  scheme  achieves  a 
utilization  close  to  1.0  for  the  AUV-II  application  which  has  a  single  independent  set 
of  processes. 

The  usefulness  of  the  scheduler  for  the  AUV-II  has  been  verified  by  creating  a 
set  of  processes  that  mimics  the  operation  of  the  AUV-II.  This  set  is  executed  at  the 
required  frequency  of  10  Hz  and,  at  the  same  time,  the  expected  response  time  for 
the  aperiodic  processes  is  achieved.  This  dummy  set  of  processes  can  be  applied  in 
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the  AUV-II  if  the  idle  loop  in  each  process  is  replaced  by  a  call  to  an  appropriate 
function  and  the  inputs  and  outputs  on  pipes  are  replaced  with  the  real  data  to  be 
transferred.  Finally,  a  framework  for  a  GUI  was  designed  and  experimented  with  to 
provide  the  functionality  required  for  easy  use  of  the  scheduler. 

B.  FUTURE  WORK 

At  present,  the  synchronization  to  be  provided  has  to  be  coded  manually  as 
described  in  Chapter  III.  This  coding  is  required  for  pipe  initialization  in  the  process 
that  is  being  called  from  the  scheduler  and  in  the  application  processes.  This  can  be 
further  improved  in  such  a  way  that  the  user  only  has  to  specify  the  names  of  the 
different  pipes,  the  processes  that  the  pipes  have  to  connect  to,  and  explicitly  specify 
which  of  those  processes  are  periodic  and  aperiodic.  An  approach  to  implement  this 
is  to  pass  the  pipes'  names  as  arguments  to  the  different  processes,  followed  by  a  flag 
that  determines  if  the  input  is  from  an  aperiodic  or  a  periodic  process. 

The  schedulability  analysis  that  has  been  provided  refers  only  to  the  processes 
timing  requirements  and  does  not  make  any  analysis  of  the  data-flow  synchronization. 
Thus,  the  scheduler  cannot  identify  inconsistencies  in  the  data-flow  diagram.  Such 
analysis  has  to  be  included  to  ensure  a  correct  application  of  the  synchronization 
technique  developed.  Techniques  that  can  be  used  for  data-flow  analysis  are  provided 
in  [Ref.  LA90]. 

Finally,  if  the  above  facilities  are  included  in  the  scheduler,  the  framework  of 
the  GUI  can  be  improved  to  become  more  user  friendly.  The  new  design,  instead  of 
displaying  the  names  and  the  attributes  of  the  different  processes,  can  display  the 
data-flow  diagram  that  those  processes  implement.  Each  process  can  be  a  node  that 
displays  the  name  and  the  attributes.  The  pipes  can  be  represented  as  arcs  between 
the  nodes.  Those  arcs  can  produce  the  required  arguments  that  will  be  given  to  the 
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processes.  The  periodic  and  aperiodic  processes  can  be  distinguished  at  this  time 
appropriately. 
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APPENDIX  A:  MAIN  FOR  RUN-TIME 

SCHEDULER 


/it***************************************************************, ***** 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

******* 

♦include 

♦include 

♦include 


Program 

Purpose 

Author 

Description 


SCHED.C  * 

MAIN  CODE  FOR  AUV-II  SCHEDULER.  * 

LTJG  D.  MAKRIS  H.N.  * 

THIS  PROGRAM,  IN  AN  INFINITE  LOOP,  CALLS  THE  MENU  * 
FUNCTION.  ACCORDING  TO  THE  USER  SELECTION,  AN  * 

APPROPRIATE  FUNCTION  IS  CALLED.  * 

THE  SELECTIONS  AVAILABLE  TO  THE  USER  ARE:  * 

1.  ADD  NEW  SET  OF  TASKS  * 

2.  VIEW  TASKS  * 

3.  CHANGE  TASKS  PARAMETERS  * 

5.  START  EXECUTION  OF  THE  TASK  SET  * 

6.  EXIT  THE  SCHEDULER  * 


<stdio .h> 
<math.h> 
<errno .h> 


♦include  <procid.h> 
♦include  <setsys.h> 
♦include  <signal.h> 
♦include  <ctype.h> 


♦define  TRUE  1 

♦define  NO  0 

♦define  DONE  1 

♦define  SIZE  15 

♦define  MAX.PRIORITY  60000 


extern 

extern 

extern 

extern 


char 


char 

char 

double 


int  kill()  ,os9forkc()  ,exit()  .interceptO  ; 

int  getpidO  ,_get_process_desc() ; 

double  atof(); 

char  **environ; 

/*  THE  FOLLOWING  ARRAYS  CONTAINS  ALL  THE  ATRIBUTES  IN 

CHARACTER  FORM  SO  THEY  CAN  BE  PASSED  AS  ARGUMENTS 
INTO  THE  PROCESSES  THAT  WILL  BE  FORKED.  */ 

♦argl [SIZE] ,*arg2[SIZE] ,*name[SIZE] , 

•Cchar [SIZE] ,*Cchar_ap[SIZE] ,*tot.Cchar [SIZE] , 

♦TcharCSIZE] ,*Tchar_ap[SIZE] ,*tot_Tchar [SIZE] ; 

*arg3 [] ‘{"start" , 0 , > ; 

*arg4 [] ‘{"pipes" , 0 , > ; 

WtSIZE] [SIZE] , Li [SIZE] [SIZE] ; 


i cpt hand ( s ignum ) 
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int  sign urn; 

/*  INTERCEPT  HANDLER  */ 

fprintf  (stderr,"I  received  signal  in  sched.c  :  */,d\n"  ,signum)  ; 

> 

main  0 

{ 

double  TCSIZE] ,T_ap[SIZE] ,tot_T[SIZE] , 

C[SIZE] ,C.ap[SIZE] ,tot_CESIZE] , 

D.apCSIZE]  ; 

int  n, aper.no, tot.no , analysis ; 

int  process.pri [SIZE] ,pid; 

procid  parent; 

char  job; 

char  oenuO; 

void  create.memory () ; 

void  add.new.setO ; 

void  view.tasksO ; 

void  change.parametersO ; 

void  make_sched_analysis() ; 

void  run_set(); 

void  stop.screenO ; 

void  my.endO; 


analysis--*); 

pid=getpid() ;  /«■  FIND  PROCESS  ID  */ 

/*  FIND  NEWSS  (START  SCHEDULER)  ID  */ 

get_process_desc(pid,  sizeof (parent) .Aparent) ; 
create.memory ();  /*  ALLOCATE  MEMORY  IN  ALL  ARRAYS  */ 

while (TRUE) 

job  =  menu ( 1 ) ;  /♦  CALL  MANY  #1  AND  GET  USERS  ORDER  */ 

switch (job){ 

case  ' 1 ' : 

analysis**) ;  /*  SCHED.  ANALYSIS  HAS’T  BE  DONE  */ 


/*  CALL  FUNCTION  THAT  TAKE  NEW  PROCESSES  VALUES  */ 
add.new.set(An,AC[0] ,AT[0]  , 

Aaper.no ,AC_ap[0] ,AT_ap[0] ,AD_ap[0] , 

Atot_C[0] ,Atot_T[C]) ; 
break; 

case  ’2'  : 

/*  CALL  FUNCTION  THAT  DISPLAYS  ATTRIBUTES  */ 
view.tasks(n,AC[0] ,AT[0] , 

aper.no ,AC_ap[0] ,AT_ap[0] ,AD_ap[0]) ; 
break; 

case  ’3’: 
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analys>is=0;  /*  SCHED.  ANALYSIS  HAS'T  BE  DONE  */ 

/*  CALL  FUNCTION  THAT  CHANGE  TASKS  ATTRIBUTES  */ 
change_parameters(n,4C[0] ,ftT[0] , 

aper.no ,ftC_ap[0] ,ftT_ap [0] ,ftD_ap[0] ) ; 
break; 

case  '4' : 

analysis*DONE; 
tot.no  *n; 

/*  CALL  FUNCTION  THAT  MAKES  SCHEDUL.  ANLYSIS  */ 
make.sched.analysis(ftC[0]  .ftTTO]  .fttot.no, 

*C_ap[0] ,ftT.ap[0] ,ftD_ap[0] , aper.no, ftprocess.pr i [0] , 
fttot.CCO] ,&tot_T[0] ) ; 
break; 

case  '5' : 

if (analysis=*DONE)  /*  IF  SCHED.  ANALYSIS  HAS  BE  DONE  */ 
/*  CALL  FUNCTION  THAT  STARTS  THE  EXECUTION  */ 
run_set(&tot_C[0] ,fttot_T[0] , 

ftprocess.pri [0] .ftparent , tot.no) ; 
else-C  /*  ELSE  GO  TO  MAIN  MANU  */ 

printf ("  YOU  MUST  FIRST  MAKE  SCHEDULABILITY  ANALYSIS\n") ; 
stop_screen() ; 

> 

break; 
case  ’6’ : 

/*  CALL  FUNCTION  THAT  KILLS  THE  NEVSS  AND  EXITS  */ 
my_end(n,aper_no,tD.ap[0] .parent) ; 

default : 

printf ("\n\t  This  is  not  a  proper  command!  Try  again. \n") ; 
stop.screenO ; 


APPENDIX  B:  FUNCTIONS  USED  BY 
RUN-TIME  SCHEDULER 
/********************************************************************* 


*  Program  :  SCHED.C  * 

*  Purpose  :  FUNCTIONS  THAT  ARE  CALLED  FROM  mainO  IN  THE  * 

*  AUV-II  SCHEDULER.  * 

*  Author  :  LTJG  D.  MAKRIS  H.N.  * 

*  Description:  THIS  CODE  CONTAINS  ALL  THE  FUNCTIONS  THAT  ARE  * 

*  BEING  CALLED  IN  THE  AUV-II  SCHEDULER.  * 

*  EACH  FUNCTION  WILL  BE  DESCRIBED  SEPARATELY.  * 

/********************************************************************* 

*  THIS  FUNCTION  PROVIDES  ALL  THE  MENUS  THAT  ARE  USED  FROM  THE  * 

*  SCHEDULER.  IT  HAS  AS  INPUT  THE  NUMBER  OF  THE  MENU  THAT  HAS  TO  * 

*  BE  DISPLAYED  AND  RETURNS  THE  USER'S  SELECTION  FROM  THAT  MENU.  * 


******+**************************************************************/ 

char  menu (chose) 

int  chose; 

{ 

int  job; 

char  bufer[5]; 

printf ("\n\n\n\n\n\n\n\n\n") ; 
switch  (chose) { 

case  1 :  /*  DISPLAYS  MAIN  MENU  */ 

printf ("\t\t\t\t\t  MAIN  MENU  \n\n") ; 

printf ("\t\t\t\t\tl  *  ADD  NEW  SET  OF  TASKS  \n") ; 
printf ("\t\t\t\t\t2  *  VIEW  TASKS  \n") ; 

printf ("\t\t\t\t\t3  «  CHANGE  PARAMETERS  \n") ; 
printf ("\t\t\t\t\t4  *  MAKE  SCHEDULABILITY  ANALYSIS\n") ; 
printf ("\t\t\t\t\t5  *  RUN  TASKS  SET  \n"); 

printf ("\t\t\t\t\t6  *  EXIT  \n"); 

break; 

case  2:  /*  MENU  WHEN  THE  USER  SELECTS  1  IN  THE 

MAIN  MENU  */ 

printf ("\n\n\n\n") ; 

printf ("\t\t\t\t\tl  «  INPUT  FROM  KEYBOARD  \n\n"); 
printf ("\t\t\t\t\t2  *  INPUT  FROM  FILE  \n\n\n")  ; 
break; 

case  3:  /*  MENU  WHEN  THE  USER  SELECTS  2  IN  THE 

MAIN  MENU  */ 

printf ("\n\n\n") ; 

printf ("\t\t\t\t\tl  *  CHANGE  PERIODIC  SET  \n\n"); 
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printf ("\t\t\t\t\t2  *  CHANGE  APERIODIC  SET  \n\n\n"); 
break; 

> 

printf ("\n\n\n\n\n\n\n\n") ; 
readln(0,bufer,2) ; 
return (buf er [0] ) ; 


/********************************************************************* 

*  THIS  FUNCTION  ALLOCATES  MEMORY  FOR  ALL  THE  STRING  ARRAYS  * 


void  create_memory() 
int  i ; 


for(i=0;i<SIZE;i++){  /*  FOR  MAX.  EXPECTED  #  OF  PROCESSES  */ 


argl[i]  =  (char  *)malloc(15) ;/*  PERIODIC  NAMES  */ 
arg2 [i]  =  (char  *)malloc(15) ;/*  APERIODIC  NAMES  */ 
name[i]  =  (char  *)malloc(15) ;/*  ALL  NAMES  */ 
TcharCi]  =  (char  *)malloc(5) ;  /*  PERIODIC  PERIODS  */ 
Cchar [i]  =  (char  *)malloc(5);  /*  PERIODIC  EXEC.  TIME  */ 
Tchar_ap[i]  =  (char  *)malloc(5) ;  /*  APERIODIC  AVER.  PERIODS  */ 
Cchar_ap[i]  *  (char  *)malloc(5);  /*  APERIODIC  EXEC.  TIMES  */ 
tot.Tchar [i]  *  (char  *)malloc(5);  /*  ALL  PERIODS  */ 
tot_Cchar [i]  *  (char  *)malloc(5) ;  /*  ALL  EXECUTION  TIMES  */ 


> 


*  THIS  FUNCTION  OBTAINS  THE  NEW  SET  OF  TASKS  THAT  THE  USER  PROVIDES.* 

*  FIRST  ASKS  THE  USER  TO  SELECT  IF  HE  WANTS  TO  ADD  FROM  A  FILE  OR  * 


*  BY  USING  THE  KEYBOARD.  THEN  CALLS  THE  APPROPRIATE  FUNCTIONS  TO  * 

*  READ  THE  NAMES  AND  THE  ATTRIBUTES.  FINALLY  MAKES  SORTING  FOR  * 

*  BOTH  PERIODIC  AND  APERIODIC  PROCESSES.  * 


*****************++**********+++*+++**++++++***++++++++++++++++++++++/ 
void  add_nev_set(n,C,T,aper_no,C_ap,T_ap,D_ap,tot_T,tot_C) 

int  *n,*aper_no; 

double  *C , *T , *C_ap , *T_ap , *D_ap , *tot_T, *tot_C; 


char  t  cb ; 


void  take_initial_values() ; 

void  short _periodics() ; 

void  short_aperiodics() ; 

void  take_aperiodic_values() ; 

void  take_from_f ile() ; 


job  -  menu(2) ;  /*  INPUT  FROM  FILE  OR  KEYBOARD  ??  */ 

svitch(jobM 

case  '1':  /*  FROM  KEYBOARD  */ 

take_initial_values (n , AC [0] ,&T[0]) ; 
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short _periodics(*n,4C[0] ,4T[0] ) ; 

take_aperiodic_values(aper_no,4C_ap[0] ,4T_ap[0] ,4D_ap[0]) ; 
short_aperiodics(*aper_no ,4C_ap[0] ,4T_ap[0] ,4D_ap[0] ) ; 
break; 

case  'V  :  /*  FROM  FILE  */ 

take.f rom_f ile (n ,4C [0] ,4T [0] , 

aper.no, 4C_ap[0] ,4T_ap[0] ,4D_ap[0]) ; 
short  .periodics  On  ,4C[0] ,4T[0] ) ; 

short.aperiodics  Oaper.no,  4C_ap[0] ,4T_ap[0] ,4D_ap[0]); 
break; 
default : 

printf ("\n\t\tNOT  a  proper  command!  \n\n"); 
stop.screenO ; 

> 

> 


/ ********************************************************************* 


*  THE  FOLLOWING  FUNCTION  RETURNS  TO  THE  PROGRAM  THE  AVERAGE  * 

*  TASK  PERIODS  T CD ,  THE  EXECUTION  TIME  C CD  AND  THE  NAMES  argl []  OF  * 

*  THE  PERIODIC  PROCESSES .  FIRST  ASK  THE  USER  FOR  THE  NUMBER  OF  * 

*  V  1I0DIC  PROCESSES  THAT  THE  SET  WILL  HAVE  AND  THEN  CALLS  A  * 

*  I  ACTION  TO  HAVE  THOSE  VALUES  ONE  AT  THE  TIME.  * 


V ****************************************************** **************/ 

void  take_initial_values(n,C,T) 
int  *n; 
double  *C,*T; 

{ 

int  i; 

void  one.periodicQ  ; 

printf ("\n\nNumber  of  periodic  processes  to  schedule  =>:"); 
scanf  ("*/.d"  ,n) ; 

for(i=0;i<*n;i++H  /*  FOR  EXPECTED  #  OF  PROCESSES  */ 

one_periodic(i,4T[0] ,4C[0]) ;/*  TAKE  ONE  AT  THE  TIME  */ 

} 


/ ********************************************************************* 

*  THIS  FUNCTION  SORTS  THE  PERIODIC  PROCESS  IN  THE  INCREASING  ORDER  * 

*  OF  PERIOD.  IF  IT  FINDS  THAT  TWO  PROCESSES  ARE  NOT  IN  THE  CORRECT  * 

*  ORDER  CALLS  THE  FUNCTION  flip.per  TO  MAKE  THE  APPROPRIATE  CHANGES.* 

********************************** ***********************************/ 
void  short_periodics(n,C,T) 

int  n; 

double  *C,*T; 

{ 

int  i , j ,a,b; 

void  flip.perQ; 
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/*  FOR  ALL  THE  PERIODICS 

/*  FOR  ALL  ABOVE  THE  SELECTED  ONE 

/*  BOUBLE  SORTING 


*/ 

*/ 

*/ 


for(i=n-l ;i>0 ;  i — ){ 
for(j=0; j<i; j++){ 
a*T [ j ]  ; 
b=T[j  +  l]; 
if(  a  >  b)  flip_per(j  ,&C[0]  ,&T[0]) ; 

> 

> 

> 

/********************************************************************* 


*  THIS  FUNCTION  SORTS  THE  APERIODIC  PROCESS  IN  THE  INCREASING  * 

*  ORDER  OF  LAXITY.  IF  IT  FINDS  THAT  TWO  PROCESSES  ARE  NOT  IN  THE  * 

*  CORRECT  ORDER  CALLS  THE  FUNCTION  flip_aper()  TO  MAKE  THE  * 

*  APPROPRIATE  CHANGES.  * 


*********************************************************************/ 

void  short_aperiodics (aper.no , C_ap , T.ap ,D_ap) 

int  aper.no ; 

double  *C_ap,*T_ap,*D_ap; 

{ 

int  i, j ,a,b; 

void  flip_aper() ; 

for(i=aper_no-l; i>0; i — ){/*  FOR  ALL  THE  APERIODICS  */ 

for(j=0 ; j<i ; j++){  /*  FOR  ALL  ABOVE  THE  SELECTED  ONE  */ 

a*D_ap [ j j -C_ap [ j ] ; 
b=D_ap  [j+l]  ~C_ap  [j  +  l]  ; 

if(  a  >  b)  flip_aper(j ,AC_ap[0] ,&T_ap[0] ,ftD_ap[0]) ; 

> 

> 

/***■*>♦♦  **********  **  ***  **********************************  *  ************* 

*  THIS  FUNCTION  CHANGES  ALL  THE  ELEMENTS  OF  THE  ARRAYS  THAT  CONCERN  * 

*  PERIODIC  TASKS  THAT  ARE  NOT  IN  THE  APPROPRIATE  ORDER  AT  THE  TIME  * 

*  OF  SORTING.  SPECIFICLY  CHANGES  THE  PERIOD  T  THE  EXECUTION  TIME  C  * 

*  THE  NAMES  IN  argl,  THE  PERIODS  AND  THE  EXECUTION  TIMES  IN  THE  * 

*  Tchar  AND  Cchar  RESPECTIVELY.  * 

*********************************************************************/ 

void  f lip_per(position,C,T) 

int  position; 

double  *C,*T; 

{ 

double  temp_T,temp_C ; 

char  temp.name [15] ; 

char  temp [5]; 

temp_T=T [position] ; 

T[position]=T[position+l]  ; 

T[position+l] «temp.T; 
temp_C*C [position] ; 

C [position] =C[position+l] ; 
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C [position+1] *temp_C ; 
strcpy (temp.name.argl  [position]  ) ; 
strcpy(argl [position] ,argl [position+1]  ) ; 
strcpy(argl [position+l] .temp .name) ; 
strcpy (temp, Cchar [position] ) ; 
strcpy(Cchar [position] .Cchar [position+1] ) ; 
strcpy(Cchar[position+l] .temp) ; 
strcpy (temp, Tchar [position]) ; 
strcpy (Tchar [position] .Tchar [position+l] ) ; 
strcpy(Tchar[position+l] .temp) ; 


/********************************************************************* 

*  THIS  FUNCTION  CHANGES  ALL  THE  ELEMENTS  OF  THE  ARRAYS  THAT  CONCERN  * 

*  APERIODIC  TASKS  THAT  ARE  NOT  IN  THE  APPROPRIATE  ORDER  AT  THE  TIME  * 

*  OF  SORTING.  SPECIFICLY  CHANGES  THE  AVERAGE  PERIOD  T_ap  THE  * 

*  EXECUTION  TIME  C_ap,  THE  RESPONSE  TIME  D_ap  THE  NAMES  IN  arg2,  THE* 

*  PERIODS  AND  THE  EXECUTION  TIMES  IN  THE  Tchar.ap  AND  Cchar_ap  * 

*  CHARACTER  ARRAYS  RESPECTIVELY.  * 


void  f lip_aper(position,C,T,D) 

int  position; 

double  *C,*T,*D; 


{ 


double  tempi; 

char  temp_name[l5]  ; 

char  temp [5]; 


templ*T[position] ; 

T[position]=T[position+l] ; 

T [position+1] *templ ; 
templ=C [position] ; 

C [position] *=C [position+1]  ; 

C [position+1] *templ ; 
templ=D[position] ; 

D [position] *D [position+1] ; 

D [position+1] «templ ; 
strcpy (temp_name,arg2 [posit  ion] ) ; 
strcpy (arg2 [position] , arg2 [position+1]) ; 
strcpy (arg2 [position+1] .tempjname) ; 
strcpy(temp,Cchar_ap[position]  ) ; 

8trcpy(Cchar.ap [position] ,Cchar_ap [position+l] ) ; 
strcpy(Cchar_ap[position+l] .temp) ; 
strcpy(temp,Tchar_ap[position] ) ; 
strcpy (Tchar.ap [position] .Tchar.ap [position+1] ) ; 
strcpy(Tchar_ap[position+l] .temp) ; 
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/******************************** ************************************* 


*  THE  FOLLOWING  FUNCTION  RETURNS  TO  THE  PROGRAM  THE  AVERAGE  * 

*  TASK  PERIODS  T_ap[],  THE  EXECUTION  TIME  C_ap[]  THE  MAX  EXECUTION  * 

*  DELAY  D_ap[]  AND  THE  NAMES  OF  THE  APERIODIC  PROCESSES.  * 

*  FIRST  ASK  THE  USER  FOR  THE  NUMBER  OF  APERIODIC  PROCESSES  THAT  THE  * 

*  SET  WILL  HAVE  AND  THEN  CALLS  THE  FUNCTION  one.aperiodic  * 

*  TO  HAVE  THOSE  VALUES  ONE  AT  THE  TIME.  * 


*********************************************************************/ 
void  take_aperiodic_values(n,C,T,D) 

int  *n; 

double  *C,*T,*D; 

{ 

int  i; 

void  one_Aperiodic() ; 

printf ("\n\nNumber  of  aperiodic  processes  to  schedule:"); 

scanf ("Xd" ,n) ; 

printf ("\n") ; 

f or(i*0 ; i<*n; i++){  /*  FOR  EXPECTED  #  OF  APERIODIC  PROCESSES*/ 

one_Aper iodic (i, AC [0]  ,AT[0]  ,&D[0])  ; 

> 


*  THE  FOLLOWING  FUNCTION  RETURNS  TO  THE  PROGRAM  THE  ALL  THE  * 

*  NAMES  AND  THE  TASKS  ATTRIBUTES  WHEN  THE  USER  DECIDES  TO  HAVE  THEM  * 

*  FROM  A  FILE.  FIRST  ASK  THE  USER  FOR  THE  NAME  OF  THE  FILE,  THEN  * 

*  OPENS  THE  FILE,  READS  THE  ATTRIBUTES  AS  CHARACTERS  AND  THEN  * 

*  CONVERTS  THEM  INTO  FLOATING  POINT  NUMBERS.  * 

*********************************************************************/ 
void  take_from_f ile(per_no,C,T, aper.no, C_ap,T_ap,D_ap) 

int  *per_no,*aper_no; 

double  *C,*T,*C_ap,*T_ap,*D_ap; 


char 

FILE 

int 


*name[15] ,*temp[5] ; 
*inf ile; 

i; 


printf ("\n\t  Which  file  do  you  want  to  use  ? 
scanf ("Xs" ,name) ; 

if (infile  *  f open (name, "r"))  /*  OPEN  THE  FILE  FOR  READING  */ 

f  scanf  (inf  ile ,  "Xd\n" ,per_no)  ;  /*  FIND  #  OF  PERIODIC  PROCESSES  */ 
f or (i*0 ; i<*per_no ; i++; {  /*  READ  ALL  THE  PERIODIC  ATTRIBUTES  */ 

f  scanf  (inf  ile,"'/, s’/,sy,s\n",argl[i]  ,Cchar[i]  ,Tchar[i]) ; 

C[i]*atof (Ccharti] ) ;  /*  CONVERT  ATTRIBUTES  INTO  REAL  #  */ 

T [i] *atof (Tchar [i] ) ; 

> 

f  scanf  (inf  ile,  ",/.d\n"  ,aper_no)  ;/*  FIND  #  OF  APERIODIC  PROCESSES*/ 
for(i*0;i<*aper_no;i++){  /*  READ  ALL  THE  APERIODIC  ATTRIBUTES  */ 
f  scanf  (inf  ile,  "*/,s*/,s'/,sy.s\n",arg2[i]  ,Cchar_ap[i]  , 
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Tchar.apEi] ,temp) ; 

C_ap[i]=atof  (Cchar_ap[i] ) ;/*  CONVERT  ATTRIBUTES  INTO  REAL#  */ 
T_ap[i3*atof  (Tchar_ap[i3)  ; 

D.ap [i] =atof (temp) ; 

> 

> 

fclose(inf ile) ; 

> 


^t*****!^************************************************************ 

*  THIS  FUNCTION  PROVIDES  THE  OPTION  TO  THE  USER  TO  SAVE  THE  TASK  * 

*  SET  NAMES  WITH  ALL  THE  ATTRIBUTES,  AT  THE  EXIT,  INTO  A  FILE  * 

*  THE  USER  HAS  ONLY  TO  SPECIFY  THE  FILE  NAME  IN  WHICH  THE  SET  WILL  * 

*  BE  SAVED.  * 

4'4‘******4'4<******  ******  *****4<4‘**********4‘******4'*4‘*4‘******************/ 

void  place_to_f ile(per_no , aper.no ,D_ap) 

int  *per_no,*aper_no; 

double  *D_ap; 

{ 

char  *name[l5] ,*temp[5] ; 

FILE  *outfile; 

int  i ; 


printf ("\n\tFile  to  save  the  tasks  in  => 
scant ("'/.s", name)  ; 

if (outfile  *  f open (name , "v" )  )  /*  OPEN  FILE  FOR  WRITING  */ 

f printf (outf ile, '7.d\n"  ,*per. no);/*  WRITE  #  OF  PERIODIC  TASKS  */ 
f or(i=0 ; iv*per_no ; i++) {  /*  WRITE  ATTRIBUTES  OF  PERIODIC  TASKS  */ 
f  printf  (outf  ile,  "'/.s  '/.s  */,s\n"  ,argl  [i]  ,Cchar[i]  ,Tchar  [i]  )  ; 

> 

f printf (outf ile, '7.d\n" ,*aper_no) ;/*  WRITE  #  OF  PERIODIC  TASKS  */ 
f or(i=0 ; i<*aper_no; i++){  /*WRITE  ATTRIBUTES  OF  APERIODIC  TASKS*/ 
f  printf  (outfile,  "’/.s  '/.s  '/,s  '/,f\n"  ,arg2[i]  , 

Cchar_ap[i] ,Tchar_ap[i] ,D_ap[i] ) ; 

> 

f close(outf ile) ;  /*  CLOSE  FILE  */ 


/***********4>4t**********4'*********************4‘********4‘4‘************* 

*  THIS  FUNCTION  IS  EXECUTED  WHEN  THE  USER  SELECTS  2  IN  THE  MAIN  * 

*  MENU.  IT  HAS  INPUTS  ALL  THE  TASK  NAMES  WITH  THEIR  ATTRIBUTES.  * 

*  A  CALL  IN  THE  stop.screen  FUNCTION  PREVENTS  THE  OUTPUT  FROM  * 

*  DISAPPEARING  ON  THE  VIDEO  DISPLAY.  * 


void  view.t asks (n,C,T, aper.no, C_ap,T_ap,D_ap) 

int  n, aper.no; 

double  *C,*T,*C_ap,*T_ap,*D_ap; 


int  i ; 
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void 


stop_screen() ; 


printf ("\n\n\n\n\n\n\n\n\n") ; 

printf  ("  . . PERIODIC  PROCESSES - \n")  ; 

printf ("\t\t  NAME  \t\tPERIOD\t  EXECUTION  TIME\n") ; 
for(i=0;i<n;i++) 

printf  ("\t\t  |*/,10s  I */,10 .  If  \t  |*/,10 .  If  \t\t  I \n"  ,argl  [i]  ,T[i]  ,C[i]  ) ; 

printf  ("  - \n\n\n")  ; 

printf ("  . . APERIODIC  PROCESSES - 

- \n") ; 

printf ("\t  NAME  \t\tPERIOD\t  EXECUTION  TIME  \tRESPONSE 

TIME\n") ; 


f or (i=0 ; i<aper_no ; i++) 

printf  ("\t  |'/.10s |*/.10 . If \t  I'/IO . lf\t\t  |'/.10.1f\t  |\n", 

arg2  [ij  ,T_ap[i]  ,C_ap[i]  ,D_ap[i]) ; 

printf ("  - 

- \n\n") ; 

stop_screen() ; 


> 


/********************************************************************* 

*  THIS  FUNCTION  ALLOWS  THE  USER  THE  CHANGE  THE  TASK  ATTRIBUTES.  * 

*  THE  FUNCTION  ASKS  THE  USER  TO  SPECIFY:  IF  HE  WANTS  TO  CHANGE  * 

*  PERIODIC  OR  APERIODIC  PROCESS,  AND  THE  NUMBER  OF  THE  PROCESS  THAT  * 

*  HE  WANTS  TO  CHANGE.  THEN  IT  CALLS  THE  APPROPRIATE  FUNCTION  TO  * 

*  HAVE  THE  NEW  ATTRIBUTES .  FINALLY  MAKES  SORTING  TO  THE  PROCESSES .  * 

void  change.parameters (per.no , C ,T , aper.no , C_ap ,T_ap , D_ap) 

int  per.no, aper.no; 

double  *C,*T,*C_ap,*T_ap,*D_ap; 

int  n; 

char  job; 


void 

void 

void 

void 


one.periodicO  ; 
one.AperiodicO ; 
short.periodicsO ; 
short.aperiodicsQ ; 


job  «  menu (3) ;  /*  CHANGE  PERIODIC  OR  APERIODIC  ??  */ 

printf ("  WHICH  TASK  DO  YOU  WANT  TO  CHANGE  (number) =>:") ; 

scanf  ("*/,d",ftn) ; 
printf  0'\n"); 
switch  (job){ 

case  *1*:  /*  IF  PERIODIC  */ 

if ((n<*per_no)A4(n>0))  { 

/*  GET  ATTRIBUTES  OF  ONE  PERIODIC  TASK  */ 
one_periodic(n-l,ftT[0] ,4C[0]) ; 
short_periodics(per_no ,AC[0] , 4T[0] ) ; 
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else  printf ("  THIS  TASK  DOES  NOT  EXISTS  \n"); 
break; 

case  '2’:  /*  IF  APERIODIC  */ 

if ((n<=aper_no)&&(n>0))  { 

/*  GET  ATTRIBUTES  OF  ONE  APERIODIC  TASK  */ 
one_Aperiodic(n-l ,&C_ap[0] ,&T_ap[0] ,4D_ap[0]) ; 
short_aperiodics(aper_no,&C_ap [0] ,&T_ap[0] ,4D_ap[0]) ; 

> 

else  printf ("  THIS  TASK  DOES  NOT  EXISTS  \n") ; 
break; 
default : 

printf ("\n  NOT  a  proper  command!  \n\n"); 

> 

stop_screen() ; 


/********************************************************************* 

*  THIS  FUNCTION  TAKES  FROM  THE  KEYBOARD  THE  NAME  AND  THE  ATTRIBUTES  * 

*  OF  ONE  PERIODIC  PROCESS  AT  THE  TIME.  IT  HAS  AS  INPUTS  THE  * 

*  POSITION  IN  THE  ARRAYS  AND  THE  ARRAYS  THAT  HAS  TO  FILL.  * 


void  one_periodic(i,T,C) 

int  i ; 


double  *C,*T; 
{ 


printf  ("\n\n\tEnter  the  name  of  the  process  #  7,d  *=>:",  (i+1)) ; 
scanf  ("’/.s"  ,argl[i])  ; 

printf  ("\n\tEnter  the  period  of  process  #  7,d  [ticks]  , (i+1)) ; 
scanf  ("7.s"JTchar[i]  ) ; 

T[i]=atof  (Tchar[i])  ; 

printf  ("\n\tEnter  the  execution  time  of  process  #*/.d  [ticks] 

(i+1)) ; 

scanf  ("'/.s"  ,Cchar  [i]  )  ; 

C [i] =atof (Cchar [i] ) ; 


/ ******************************************************** ************* 

*  THIS  FUNCTION  TAKES  FROM  THE  KEYBOARD  THE  NAME  AND  THE  ATTRIBUTES  * 

*  OF  ONE  APERIODIC  PROCESS  AT  THE  TIME.  IT  HAS  AS  INPUTS  THE  * 

*  POSITION  IN  THE  ARRAYS,  AND  THE  ARRAYS  THAT  HAS  TO  FILL.  * 


void  one_Aperiodic(i ,C,T,D) 
int  i ; 


double  *C,*T,*D; 
{ 


printf ("\n\n\tEnter  the  name  of  the  process  #  %d  *>:" 
scanf  ("*/.s",arg2[i]) ; 

printf ("\n\tEnter  the  average  period  of  process  #  7d 
scanf  ("*As”,Tchar_ap[i] ) ; 


, (i+1)) ; 

[ticks]=>:", 

(i+1)); 
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> 


T [i] =atof (Tchar_ap [i] ) ; 

printf ("\n\tEnter  the  execution  time  [ticks]  =>:"); 
scanf  ('"/.s"  ,Cchar_ap[i] ) ; 

C [i] *atof (Cchar_ap [i] ) ; 

printf  ("\n\tEnter  the  max  responce  time  of  process  #*/,d 
scanf  C7.F,,,4D[i]>; 


[ticks] => : " , 
(i+l»; 


/**************************************************************♦****** 

*  THIS  FUNCTION  CALLS  ALL  THE  REQUIRED  FUNCTIONS  IN  ORDER  TO  MAKE  * 

*  SCHEDULABILITY  ANALYSIS.  IT  ALSO  CALLS  THE  FUNCTION  THAT  RETURNS  * 

*  THE  PRIORITIES  THAT  WILL  BE  ASSIGNED  IF  THE  USER  DECIDES  TO  RUN  * 

*  THE  SET  OF  TASKS.  * 

*********************************************************************/ 
void  make.sched.analysis (C.T ,n ,C_ap ,T_ap , D_ap , 

aper.no .process.pri ,tot_T,tot_C) 
int  *process_pri,*n, aper.no; 

double  *C , *T , *C_ap , *T_ap , *D_ap , *tot_T , *tot_C ; 

{ 

int 

double 
double 

void 
void 
void 
void 
int 
int 
void 
void 


i , count , LCM , check ; 
per.util ; 

sched.pt [SIZE*2] , Lint [SIZE]  ; 

create_total_array() ; 
f ind_Wi() ; 
f ind_Li() ; 
f ind_min_Li() ; 
f ind_if_schedulable() ; 
least_common_mult() ; 
check_aper() ; 
assign_priorities() ; 


/*  CREATE  AN  ARRAY  IN  WHICH  BOTH  PERIODIC  AND 
APERIODIC  PROCESSES  WILL  BE  PLACED  */ 
create_total_array(n,4C[0] ,4T[0] ,  Atot_C[0] ,fttot_T[0] ) ; 

/*  CREATE  ALL  THE  INFOS  NEEDED  FOR  THE  PERIODIC  ANALYSIS  */ 
count=f ind_sched_points(4T[0] , ftsched.pt [0] ,*n) ; 
f ind.Wi (ftC[0] ,ftT[0] .ftsched.pt [0] ,*n, count) ; 
find_LiCftsched.pt [0] ,*n, count) ; 
f ind_min_Li(ftLint [0] ,*n, count); 

/*  WITH  THOSE  INFOS  FIND  IF  PERIODIC  PROCESSES  ARE  SCHEDULABLE  */ 
check*f ind_if_schedulable(ftper_util,ftLint [0] ,ftC[0] ,ftT[0] ,*n) ; 

/*  FIND  LEAST  COMMON  MULTIPLIER  OF  PERIODIC  PROCESSES  PERIODS  ♦/ 
LCM=least_common.mult(tT[0] ,*n) ; 


/*  IF  PERIODIC  SET  SCHEDULABLE  MAKE  SCHEDULABILITY  ANALYSIS  FOR  THE 
APERIODIC  SET  AND  PLACE  THE  APERIODIC  TASKS  IN  THE  COMMON  ARRAYS*/ 
if (check  **  TRUE)  check_aper(LCM,per_util ,fttot_C[0] ,fttot_T[0] , 

ftC_ap[0] ,ftT_ap[0] ,ftD_ap[0] ,n, aper.no) ; 
/*  FIND  THE  PRIORITIES  THAT  WILL  BE  ASSIGNED*/ 
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assign_prioriti.es (&tot_T[0]  ,4tot_C[0]  .fcprocess.pri [0]  ,LCM,*n)  ; 


> 

/********************************************************************* 

*  THIS  FUNCTION  CREATES  ARRAYS  WITH  ELEMENTS  ALL  THE  PERIODIC  NAMES  * 

*  AND  ATTRIBUTES.  LATER  IN  THOSE  ARRAYS  WILL  BE  PLACED  THE  * 

*  APERIODIC  NAMES  AND  ATTRIBUTES.  * 

*********************************************************************/ 
void  create_total_array(per_no ,C,T,tot_C,tot_T) 

int  *per_no ; 

double  *C,*T,*tot_T,*tot_C; 

f 

w 

int  i ; 

for(i*0; i<*per_no; i++){  /*  FOR  #  OF  PERIODIC  PROCESSES  */ 

tot_T[i]=T[i]  ; 
tot_C[i]*C[i]  ; 
strcpy (name [i] , argl [i] ) ; 
strcpy(tot_Tchar[i] ,Tchar[i]  ) ; 
strcpy (tot.Cchar [i] .Cchar [i] ) ; 

> 

> 

/it******************************************************************** 

*  THE  FUNCTIONS:  f ind_sched_points() ,  find_Wi(),  f ind_min_Li() ,  * 

*  find.LiO  and  f ind.if _schedulable()  ARE  NEEDED  FOR  SCHEDULABILITY  * 

*  ANALYSIS  OF  THE  PERIODIC  PROCESSES.  ALL  OF  THEM  ARE  PART  OF  THE  * 

*  rate.mono  PROGRAM  IN  Ref.tLe9l].  ONLY  MINOR  MODIFICATIONS  HAVE  * 

*  BEEN  DONE  AND  THEY  HAVE  BEEN  SEPARATED  TO  FORM  MODULAR  FUNCTIONS.* 

*  FOR  THAT  REASON  THEY  HAVE  BEEN  LEFT  WITHOUT  COMMENTS.  * 

*********************************************************************/ 

int  f ind_sched_points(T,sched_pt ,n) 

double  *T,*sched_pt; 
int  n; 

{ 

int  i, j ,k,p,flag, count; 

double  S; 

count=0 ; 

for(i*0; i<n;i++){ 

for(j*0; j<*i; j++){ 

for(k=l ;k<*floor(T[i]/T[j]) ;k++){ 
flag=0; 

S=k*T[j]  ; 

for(p=l ;p<count ;p++){ 
if (S*=sched_pt [p] ) 
flag-1; 

if (flag*=0){ 

sched.pt [count] *S ; 
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count++ ; 

> 

> 

> 

> 

return (count) ; 

} 

void  f ind_Wi(C,T, sched.pt, n, count) 

double  *C,*T,*sched_pt ; 
int  n , count ; 

int  i.j.t; 

double  terml ; 

terml*0; 

for(i*0;i<n;i++){ 

f or(t=0 ;t<count ;t++){ 
for(j*0; j<i; j++){ 

terml*terml+C[j]*ceil (sched.pt [t]/T[j]) ; 

> 

W[i] [t] “terml ; 
terml=0 ; 

> 

> 

> 

void  find.Li (sched.pt, n, count) 

double  *sched_pt; 
int  n , count ; 

{ 

int  i,t; 


for(i*0; i<n;i++){ 

for(t*0;t<count;t++){ 

Li[i]  [t]*(W[i]  [t]/sched.pt[t]) ; 

> 

> 


void  find.min.Li (Lint, n, count) 

double  *Lint; 
int  n, count; 

{ 

int  i ,  t  ; 

for(i*0; i<n;i++)  Lint [i] *10000; 
for(i*0; i<n;i++){ 

for(t*0;t<count ;t++){ 
if (Li [i] [tj  <Lint [i] ) 
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Lint[i]=Li[i]  [t]  ; 

> 

> 

> 

int  f ind.if _schedulable(per_util .Lint ,C,T,n) 

double  *Lint,*C,*T,*per_util; 
int  n; 

int  i, check; 

double  L,U; 

L*0; 

f or C i— 0 ; i<n;i++){ 
if (Lint [i] >L) 

L*Lint  [i] ; 

} 

U=0 ; 

for(i“0;i<n;i++)  U=U+C[i] /T[i]  ; 

*per_util*U ; 

if ( (L<=1)  &  (U<=1)){ 

printf ("\tPeriodic  process  set  SCHEDULABLE. \n\n") ; 
check=TRUE; 

> 

if ( CL> 1 ) I  I (U>1)){ 

printf ("\tPeriodic  Process  set  NOT  schedulable\n\n") ; 
check=N0 ; 

> 

printf  ("\tRemaining  processor  time  for  aperiodics  :  */.  .2f", 

(l-U)*100); 

printf ("  percent\n\n") ; 
stop_screen() ; 
return (check) ; 

> 


/********************************************************************* 

*  THE  FOLLOWING  FUNCTION  COMPUTES  THE  LEAST  COMMON  MULTIPLE  OF  THE  * 

*  PERIODIC  PROCESSES  PERIODS.  THE  PERIODS  ARE  INSERTED  IN  A  * 

*  TEMPORARY  ARRAY.  BY  DIVIDING  THE  ARRAY  ELEMENTS  WITH  ALL  THE  * 

*  INTEGERS  FROM  1  TILL  MAX  PERIOD  AND  BY  LOOKING  WHEN  THIS  DIVISION  * 

*  IS  EXACT  WE  CAN  FIND  THE  LCM.  * 

ft********************************************************************/ 

int  least_common_mult(T,n) 

double  *T ; 
int  n; 

{ 

int  i, j ,1, flag, temp; 

int  temp_period[SIZE] ; 

for(l*0;l<n;l++)  temp_period[l]=T[l] ;/*  CREATE  TEMPORARY  ARRAY  */ 
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temp=l ;  /*  temp  *  LCM  */ 

f or(i*2 ; i<*T[0] ;){  /*  fOR  ALL  INTEGERS  UNTIL  T  MAX  */ 

flag=0; 

for(j=0;j<n;j++){  /*  FOR  ALL  ELEMENTS  FOR  THAT  INTEGER  */ 

if ((temp_period[j]/i)*i  «*  temp_period[j] ){ 

/*  CHECK  IF  ANY  ELEMENT  DIVISIBLE  */ 

temp_period[j]*temp_period[j]/i; 


f lag*l ;  /*  IF  YES  DIVIDE  AND  KEEP  THE  INTEGER  */ 

> 

> 

if  (flag  «  1)  temp=temp*i;/*  MULTIMPLY  LCM  BY  THE  INTEGER  */ 
else  i++; 

> 

return (temp) ; 


/********************************************************************* 

*  THIS  FUNCTION  FINDS  IF  THE  TASK  SET  TOGETHER  WITH  THE  APERIODIC  * 

*  PROCESSES  IS  SCHEDULABLE.  FIRST  CHECKS  THE  TOTAL  PROCESSOR  UTILIZA-* 

*  TION.  IF  IS  >  1.0  EXITS  THE  FUNCTION.  IF  IT  IS  NOT,  CHECK  IF  THE  * 

*  APERIODIC  TIMING  REQUIREMENTS  CAN  BE  SATISFIED.  EITHER  WAY  CONTI-  * 

*  NUES.  THEN  FOR  EVERY  APERIODIC  PROCESS  TRIES  TO  FIND  THE  OPTIMUM  * 

*  AMONG  THE  OTHER  PROCESSES  POSITION.  ACCORDING  TO  THAT  THE  * 

*  PRIORITIES  WILL  BE  ASSIGNED,  AND  PLACES  THE  PROCESS  TH~RE.  * 

*********************************************************************/ 
void  check.aper (LCM , per.ut il ,C , T , C_ap ,T_ap , D_ap ,n , aper.no) 

double  per.ut il , *C , *T , *C_ap , *T_ap , *D_ap ; 
int  LCM, *n, aper.no; 

{ 

double  U,min_D,total_laxity ; 

int  i ,j ,a,b, place; 

char  buffer [5] ; 

int  look.blockingO ; 

int  f ind_place_for_aperiodic() ; 

double  find.total. laxity () ; 

void  place.aperiodicO ; 


U=0 ; 

/*  FIND  APERIODIC  PROCESSOR  UTILIZATION  */ 
for(i«0;i<aper.no;i++)  U=U+C_ap[i]/T_ap[i] ; 

if ((per_util+U)<»l)  {  /*  IF  TOTAL  PROCESSOR  UTILIZATION  <  1.0  */ 

printf ("\tTotal  process  set  with  aperiodics  SCHEDULABLE\n\n") ; 

/*  CHECK  IF  APERIODIC  TIMING  REQUIREMENTS  CAN  BE  SATISFIED  */ 
if ((place*look.blocking(aper.no,tC_ap[0] ,*D_ap[0] ))  !«  -1){ 

/*  IF  THEY  CANNOT  PRINT  */ 

printf ("\tBut  responce  time  of  %s  process" , arg2 [place] ) ; 
printf ("  may  NOT  be  acheived\n\n") ; 

> 


for(i«0;i<aper_no;i++){/*  FOR  ALL  THE  APERIODIC  PROCESSES  */ 

/*  FIND  LAXITY  OF  COMBINED  PROCESS  */ 
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> 


total_laxity=f ind_total_laxity(i , aper.no, &C_ap[0] ,4D_ap[0]) ; 
for(j=i; j<aper_no; j++){/*  find  min  resp.  time  for  conbined  */ 
a=D_ap  [j] ; 
b=min_D; 

if C  a<b  )  min_D=D_ap[j] ; 

>  /*  FIND  PLACE  IN  THE  ARRAY  FOR  COMBINED  APERIODIC  */ 

place*f ind_place_for_aperiodic(min_D,4C[0] ,4T[0] , 

total_laxity,*n,place+l) ; 
/*  PLACE  APERIODIC  IN  THAT  POSITION  */ 


place_aperiodic(*n .place, i,4C[0] ,4T[0] ,4C_ap[0] ,4T_ap[0]) ; 
*n=*n+l ;  /*  LOWEST  POSITION  NEXT  APERIODIC  CAN  BE  PLACED  */ 


> 


/*  THIS  IS  FOR  USER  INFORMATION  */ 

printf("\tDo  you  want  to  see  the  whole  set  (y,n)?  \n\n") ; 
readln(0, buffer, 2) ; 
if ((buffer [0] *='y’) I Ibuff er[0]==’Y’){ 

printf ("\t\t  NAME  \t\tPERIOD\t  EXECUTION  TIME\n") ; 
for(i=0;  i<*n;i++)  printf  ("\t\t  I '/,10s  I'/,  10.  lf\t  |*/,10.  lf\t\t  l\n", 

nameti]  ,T[i]  ,C[i])  ; 


> 


> 

else{  /*  IF  TOTAL  PROCESSOR  UTILIZATION  >  1.0  */ 

printf ("\tTotal  set  NOT  schedulable\n\n") ; 

printf ("\tThe  set  exceeds  processor  time  by  :  %.2f  percent \n\n" , 

(U+per_util-l)*100) ; 


stop_screen() ; 


/**  *******0**^^*OLilt**4HHm^H,t  ******************************************* 

*  THIS  FUNCTION  COMPUTES  THE  TOTAL  LAXITY  (MIN.  RESPONSE  TIME  -  SUM  * 

*  OF  EXECUTIONS)  OF  THE  COMBINED  APERIODIC  PROCESS  * 

*********************************************************************/ 
double  f ind_total_laxity (base , aper.no ,C_ap,D_ap) 

int  base.aper.no; 
double  *C_ap,*D_ap; 

{ 

int  j.a.b; 

double  min.D , sum.C; 


sum_C=0 . 0 ; 

min_D*100000 . 0 ;  /*  JUST  A  BIG  NUMBER  */ 

f or ( j *base ; i <aper_no ; j  +♦ ) {/*  FOR  APERIODICS  THAT  HAVEN'T  CHECKED  */ 
a=D_ap  [j ] ; 

b*min_D ;  /*  FIND  MINIMUM  RESPONSE  TIME  */ 

if(  a<b  )  min_D=D_ap[j] ; 

sum_C=sum_C+C_ap [j] ;  /*  COMPUTE  SUM  OF  EXECUTION  TIMES  ♦/ 

>  /*  RETURN  TOTAL  LAXITY  IF  >  0  */ 

if ( (a= (min.D- sum.C) )>0)  return(min.D-sum.C) ; 

else  return(O.O);  /*  RETURN  0  */ 
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T 


/********************************************************************* 

*  THIS  FUNCTION  FINDS  IF  THE  APERIODIC  SET  CAN  MEET  ITS  TIMING  * 

*  REQUIREMENTS.  IF  THE  SUM  OF  THE  EXECUTION  TIMES  OF  THE  PROCESSES  * 

*  WITH  HIGHER  TIMING  REQUIREMENTS  IS  GREATER  THAN  THE  RESPONSE  TIME  * 

*  OF  A  PROCESS  i  THEN  THE  PROCESS  i  MAY  NOT  MEET  ITS  RESPONSE  TIME  * 

*  WHEN  ALL  START  SIMULTANEOUSLY.  IN  THAT  CASE  THE  PROGRAM  RETURN  * 

*  THE  NUMBER  OF  THE  i  PROCESS.  OTHERWISE  RETURNS  -1  * 

******************************************************* ********* *****/ 
int  look_blocking(aper_no ,C_ap ,D_ap) 

int  aper_no; 

double  *C  ap,*D_ap; 

{ 

int  i , j , a; 

double  sum_C; 

f or(i=aper_no-l ;  i>0 ;  i — )■£/*  FOR  ALL  THE  APERIODIC  PROCESSES  */ 

sum_C=0 . 0 ; 

/*  FIND  SUM  OF  THE  EXECUTIONS  TIMES  FOR 

PROCESSES  WITH  LOWER  LAXITY  */ 
f or(j=0 ; j<i ; j++)  sum_C=sum_C+C_ap[j] ; 
a=D_ap [i] -C_ap  [i] -sum_C ; 

if (a<0)  return(i) ;  /*  IF  RESPONSE  TIME  SMALLER  THAN  THE  SUM 

RETURN  THE  NUMBER  OF  THE  PROCESS  */ 

> 

return(-l);  /*  ELSE  RETURN  -1  */ 


/********************************************************************* 

*  THIS  PROCESS  COMPUTES  THE  PRIORITIES  THAT  WILL  ASSIGNED  TO  THE  * 

*  PROCESSES  IF  THE  USER  DECIDES  TO  RUN  THE  SET.  THE  CODE  IS  FROM  * 

*  rate.mono  PROGRAM  in  Ref.[Le9l]  WITH  THE  MODIFICATION  THAT  IT  HAS  * 

*  BECOME  A  FUNCTION  AND  INSTEAD  OF  GIVING  AS  INPUT  ONLY  THE  PERIODIC* 

*  PROCESSES,  THE  COMBINED  ARRAY  OF  PROCESSES  IS  PROVIDES.  FOR  THAT  * 

*  REASON  THE  COMMENTS  HAVE  BEEN  OMITTED.  * 


**************************** 


void  assign_priorities(T,C,process_pri ,LCM,n) 

double  *T,*C; 

int  *process_pri ; 

int  LCM,n; 


{ 


double  temp , tempi ,temp2 ; 

int  i.j.k.l; 


process.px i [0] =MAX_PRIORITY ; 
temp=l ; 
templ=0 ; 
temp2=l ; 

for(i=l;i<n;i++){ 
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for ( j  =0 ; j <= (i- 1) ; j++)  temp2=temp2*T[j] ; 
for(k=0;k<=(i-l) ;k++){ 
f or(l=0 ; l<*(i-l) ;l++){ 
if(l!=k)  temp=temp*T[l] ; 

> 

temp 1-temp 1+C [k] *temp ; 
temp=l ; 

> 

process.pri  [i] =process_pri [0] -ceil(LCM* (templ/temp2)*5*i) ; 

templ*0; 

temp2=l ; 

templ=0 ; 

for(i=0;i<n;i++){ 
if (T[i]>templ) 
templ=T[i] ; 

> 

f or (i=l ; i<n ; i++)  process.pri [i] =process_pri [0] - (i*templ) ; 


/*******************, ************************************************** 

*  THIS  FUNCTION  INSERT  THE  NAME  AND  THE  ATTRIBUTES  OF  AN  APERIODIC  * 

*  PROCESS  IN  THE  ARRAYS  THAT  CONTAINS  BOTH  PERIODIC  AND  APERIODIC  * 

*  PROCESSES.  THIS  IS  DONE  BY  MOVING  ALL  THE  ELEMENTS  THAT  ARE  BELOW  * 

*  THE  SPECIFIED  POSITION  ONE  STEP  DOWN  AND  THEN  INSERTING  THE  NEW  * 

*  ELEMENTS .  * 


********************** 


void  place_aperiodic(n, place, aper ,C,T,C_ap,T_ap) 
double  *C,*T,*C_ap,*T_ap; 


int 

{ 


n, place, aper; 


int  i ; 


f or (i=n ; i>place ; i — ){/*  MOVE  ELEMENTS  BELOW  place  ONE  STEP  DOWN  */ 
strcpy(name[i] ,name[i-l] ) ; 

C[i]=C[i-l]  ; 

T[i]=T[i-l]  ; 

strcpy (tot_Cchar [i] ,tot_Cchar [i-1] ) ; 
strcpy (tot _Tchar[i] ,tot_Tchar [i-l] ) ; 

>  /*  INSERT  NEW  ELEMENTS  */ 

strcpy (name [place] ,arg2[aper]) ; 

strcpy (tot_Cchar [place] ,Cchar_ap[aper] ) ; 

strcpy (tot.Tchar [place] ,Tchar_ap[aper] ) ; 

C [place] «C_ap [aper] ; 

T [place] *T_ap [aper] ; 
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*  THIS  FUNCTION  FINDS  THE  BEST  POSITION  FOR  A  COMBINED  APERIODIC  * 

*  PROCESS  TO  HAVE  ITS  PRIORITY.  STARTS  LOOKING  IF  THE  RESPONSE  TIME  * 

*  CAN  BE  ACHIEVED  BY  GIVING  THE  LOWEST  PRIORITY.  IF  NOT  IS  GOING  * 

*  POSITION  LOWER.  IT  CANNOT  GO  LOWER  THAN  THE  LAST  ASSIGNED  PRIO-  * 

*  RITY.  THAT  IS  FOR  THE  CASE  THE  APERIODIC  PROCESSES  CANNOT  * 

*  ACCOMPLISH  THE  REQUIRED  RESPONSE  TIME  BUT  THE  USER  STILL  WANTS  TO  * 

*  RUN  THE  SET.  * 


*********************************************************************/ 


int  f ind_place_f or_aper iodic (minD , C ,T .Delay ,n , last) 

double  *C,*T, minD, Delay; 
int  n,last; 

{ 

int  i ; 

double  U; 

U=0 ; 

/*  FIND  WORST  CASE  PROCESSOR  UTILIZATION  DURING  RESPONSE  TIME*/ 
for(i=0;i<n;i++)  U=U+ceil(minD/T[iJ )*C[i] ; 

while ((Delay<(U))  A&  (n>last)){  /*  WHILE  TIME  NEEDED  FOR  OTHER 

PROCESSES  GREATER  THAN  RESPONSE  TIME  */ 
n— ;  /*  GO  ONE  POSITION  LOWER  */ 

U=0 ;  /*  FIND  PROCESSOR  UTILIZATION  WITH  ONE  PROCESS  LESS  */ 

f or(i=0 ; i<n; i++)  U=U+ceil(minD/T[i])*C[i] ; 

> 

return(n) ;  /*  RETURN  THE  OPTIMUM  POSITION  */ 


/********************************************************************* 


*  THIS  FUNCTION  FIRST  CALLS  THE  TASK  THAT  CREATE  ALL  THE  PIPES.  * 

*  THEN  SAVES  SOME  STATISTISTICAL  INFORMATION  IN  A  FILE  FOR  LATER  * 

*  USER  ANALYSIS.  THEN  CREATES  ALL  THE  TASKS.  * 

*  THEN  SENDS  SIGNALS  TO  ALL  OF  THEM  TO  START  EXECUTION  FINALLY  * 

*  WAITS  FOR  PROCESSES  TO  FINISH  EXECUTION  AND  CLOSES  THE  PIPES.  * 


**********************> 


void  run_set(C,T,process_pri .parent ,n) 

int  *process_pri ,n; 

double  *C,*T; 
procid  *parent; 

{ 


FILE  *file; 

int  pid, pipes. id, prid[SIZE] ; 


int  create.pipesO ; 

void  save_priorities() ; 

void  f ork_the_processes() ; 

void  start_processes() ; 

void  receive_send_kill() ; 


pid=getpid();  /*  GET  PROCESS  ID 


*/ 
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> 


pipes_id=create_pipes() ;  /*  CREATE  ALL  THE  PIPES  */ 

if (  f ile=f open("statist" ,  "v"))/*  SAVE  IN  FILE  ASSIGNED  PRIORIT.*/ 
save_priorities(f ile,&C[0] ,&T[0] ,&process_pri [0] ,n) ; 
else 

printf  ("\tcannot  open  '/.s  to  save  priority  inf o\n\n" ."statist")  ; 

/*  CREATE  ALL  THE  TASKS  */ 

f ork_the_processes(iprocess_pri [0] , tprid[0] .parent ,n) ; 
f close(f ile) ; 

start_processes(Jtprid[0]  ,n)  ;/*  START  EXECUTION  OF  TASKS  */ 

receive.send.kill (pipes.id, *parent ,n) ; 

/*  WAIT  FOR  TASK  TO  END  AND  CLOSE  ALL  THE  PIPES  */ 


/********************************************************************* 

*  THIS  FUNCTION  IT  JUST  SAVES  THE  TASKS  PRIORITIES  AND  SOME  OF  THE  * 

*  TASKS  ATTRIBUTES  IN  A  FILE  FOR  LATER  ANALYSIS.  * 

*********************************************************************/ 
void  save_priorities(f ile,C,T,process_pri ,n) 

FILE  *f ile; 

double  *C,*T; 

int  *process_pri ,n; 

{ 

int  i ; 

fprintf (file, 

"process#  \t 
for(i=0;i<n;i++){ 
fprintf (file, 

"'/.6d  \t'/,5s 

> 

fprintf (f ile,"\n\n") ; 


/*******************************************************************%* 

*  THIS  FUNCTION  FORKS  THE  PROCESS  pipes. c  THAT  CREATES  ALL  THE  PIPES* 

*  AND  THEN  IT  FORKS  THE  FUNCTION  start. c  THAT  GIVES  INITIAL  VALUES  * 

*  IN  SOME  OF  THE  PIPES  SO  THE  AUV-II  CAN  START  EXECUTION  * 

********************************************************* !************/ 

int  create_pipes() 

int  pipes. id, start.id; 

if ((pipes_id*os9exec(os9forkc,arg4[0] , arg4, environ, 0, 61000, 15) )<0) 

•C  /*  FORK  pipes. c  TASK  */ 

fprintf  (stderr, "Cannot  fork  '/,s  \n" , "pipes")  ; 
exit (errno) ; 

> 

pauseO ;  /*  WAIT  FOR  pipes. c  TO  FINISH  EXECUTION  */ 

if ((start. id*os9exec(os9forkc,arg3[0] ,arg3, environ, 0,61000, 15))<0) 

{  /*  FORK  start. c  TASK  */ 


name  \texec.  timeYt  period  \tpriority\n") ; 

\t%9.1f  \t  */.5.1f  \t*/.  %8d\n"  ,  (i+l)  .name [i]  , 

C [i] ,T [i] ,process_pri [i] ) ; 
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fprintf  (stderr, "Cannot  fork  '/.s  \n"  , "start")  ; 
exit(errno) ; 

> 

return (pipes_id) ; 


/******* ************************************************************** 

*  THIS  FUNCTION  FORKS  ALL  THE  PROCESSES  IN  THE  DATA-FLOW  DIAGRAM.  * 

*  THE  ARGUMENTS  THAT  ARE  PASSED  ON  THOSES  PROCESSES  ARE  THEIR  NAMES,* 

*  THEIR  EXECUTION  TIMES  C,  AND  THEIR  PERIODS  T.  THE  PRIORITIES  ARE  * 

*  THOSE  THAT  HAVE  ALREADY  BEEN  COMPUTED.  AFTER  EACH  FORKING  THE  * 

*  PROGRAM  SUSPENDS  ITSELF  UNTIL  THE  PROCESS  FINISHES  INITIALIZATION.* 
*********************************************************************/ 
void  f ork_the_processes(process_pri ,prid, parent ,n) 

int  *process_pri ,*prid,n; 

procid  *parent ; 

int  i ,pid,token_id; 

char  *lalal[4]; 


lalal [0]=(char  *)malloc(15) ; 
lalal [l] = (char  *)malloc(5) ; 
lalal [2]=(char  *)malloc(5) ; 
lalal [3] =NULL; 
pid=getpid() ; 

for(i=0; i<n;i++){  /*  FOR  ALL  THE  PROCESSES  */ 

strcpy (lalal [0], name [i]);/*  COPY  THE  ARGUMENTS  IN  TEMP.  ARRAY  */ 
strcpy(lalal [l] ,tot_Cchar[i] ) ; 
strcpy (lalal [2] ,tot_Tchar [i] ) ; 

/*  FORK  THE  PROCESSES  */ 

if ( (prid [i] *os9exec (os9f orkc .lalal [0] , lalal , environ , 0 , 

process_pri[i] ,15))<0) 

fprintf (stderr ."Cannot  fork  %s  \n" ,argl [i] ) ; 
exit (errno) ; 

> 

pause () ;  /*  WAIT  FOR  PROCESS  TO  BE  INITIALIZED  */ 


*  THIS  FUNCTION  IS  WAITING  FOR  ALL  THE  PROCESSES  IN  THE  DATA-FLOW  * 

*  DIAGRAM  TO  FINISH  EXECUTION.  THEN  IT  SENDS  A  SIGNAL  IN  THE  PROCESS* 

*  pipes. c  THAT  CREATED  ALL  THE  PIPES  TO  FINISH  EXECUTION.  * 


********************„ 


void  receive_send_kill(pipes_id, parent ,n) 

int  pipes_id,n; 

procid  parent; 


intkillerr, i ; 
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for(i=0;i<n;i++)  pauseO;/*  WAIT  ALL  THE  PROCESS  TO  FINISH  */ 

if ((killerr=kill(pipes_id,SIGWAKE))  ==  -1)  fprintf (stderr , 

cannot  vakeup  pipes. c  in  */,s,  error  No  =*/,d\n",  "sched.c",errno) ; 
>  /*  SIGNAL  pipes. c  TO  FINISH  EXECUTION  */ 

/********************************************************************* 

*  AFTER  THE  INITIALIZATION  EACH  PROCESS  IN  THE  DATA-FLOW  DIAGRAM  * 

*  SUSPEND  ITSELF.  THIS  FUNCTION  SENDS  KILL  SIGNALS  IN  ALL  THE  * 

*  PROCESSES  SO  THEY  CAN  START  SIMULTANEOUSLY  THE  EXECUTION  OF  THEIR  * 

*  MAIN  LOOPS.  * 


void 

int 

{ 

int 


start .processes (prid ,n) 
*prid,n; 

killerr.i; 


for(i=0;i<n;i++){ 

if ((killerr=kill(prid[i] .SIGWAKE))  *=  -1)  fprintf (stderr, 

"Cannot  vakeup  process  #  */,d  in  */,s,  error  No  «*/,d\n" , 

prid[i] ,"sched.c",errno) ; 

> 


*  THIS  FUNCTION  IS  BEING  CALLED  WHEN  THE  USER  DECIDES  TO  EXIT  THE  * 

*  SCHEDULER.  FIRST  PROVIDES  THE  OPTION  TO  THE  USER  TO  SAVE  THE  TASKS* 

*  SET.  THEN  RELEASES  ALL  THE  MEMORY  THAT  HAS  BEEN  USED  WITH  malloc.  * 

*  THEN  IT  SENDS  A  SIGNAL  TO  THE  PARENT  PROCESS  (nevss.c)  TO  FINISH  * 

*  EXECUTION  AND  THEN  IT  EXITS .  * 

*********************************************************************/ 
void  my.end (n , aper.no , D.ap , parent) 

int  n, aper.no; 

double  *D_ap; 
procid  parent; 

{ 

char  bufer[5] ; 


void  place.to.f ile() ; 

void  return.memory () ; 

void  parent .kill () ; 

printfO'YtDo  you  want  to  save  the  tasks  in  file  (y,n)  ?\n") ; 
readln(0,bufer,2) ;  /*  OPTION  IN  USER  TO  SAVE  THE  SET  */ 

printf ("\n") ; 

if ((bufer[0]**’y’) I  I (bufer[0]«=’Y’)) 

place.to.f ile(ftn .taper.no ,tD_ap[0] ) ; 
return.memory () ;  /*  RELEASE  THE  USED  WITH  malloc  MEMORY  */ 

parent.kill (parent);  /*  KILL  THE  START  SCHEDULER  (nevss.c)  */ 

exit() ; 
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*  THIS  FUNCTION  SENDS  A  SIGNAL  TO  newss.c  TO  FINISH  EXECUTION  * 

*********************************************************************/ 
void  parent.kill (parent) 

procid  parent; 

{ 

int  killerr; 

if ((killerr=kill (parent. _pid,SIGWAKE))  ==  -1)  fprintf (stderr , 

"Cannot  wakeup  newss.c  in  '/.s,  error  No  =*/,d\n",  "sched.c" ,errno) ; 

> 

/********************************************************************* 

*  THIS  FUNCTION  IS  BEING  CALLED  AFTER  EVERY  SCHEDULER  OUTPUT  SO  IT  * 

*  WILL  STOP  THE  SCROLLING  OF  THE  SCREEN.  * 

*********************************************************************/ 

void  stop_screen() 

char  hit[lO]; 

printf("\n\t  Hit  RETURN  to  continue. \n  "); 
readln(0,hit,l) ; 
printf ("\n\n") ; 

> 


/********************************************************************* 


*  THIS  FUNCTION  RELEASES  ALL  THE  MEMORY  ALLOCATIONS  BEFORE  EXIT 
******** 

void  return_memory() 


int  i ; 

f or (i=0 ; i<SIZE; i++){  /*  FOR  MAX  EXPECTED  #  OF  PROCESSES  */ 

f ree(argl [i] ) ; 
f ree(arg2 [i] ) ; 
f ree(name[i] ) ; 
freeCCchar [i] ) ; 
free (Cchar.ap [i] ) ; 
free (tot_Cchar [i] ) ; 
free(Tchar [i] ) ; 
free (Tchar.ap [i] ) ; 
f ree (tot _T char [i] ) ; 


APPENDIX  C:  CODE  FOR  CALLED 

PROCESSES 


/********************************************************************* 


* 

* 

* 

* 

* 

* 

* 


Program 

Purpose 

Author 

Description 


GUIDANCE. C 

CODE  FOR  CALLED  PROCESSES. 

LTJG  D.  MAKRIS  H.N. 

THIS  IS  GENERIC  DUMMY  PROCESS  BEING  USED  TO  VERIFY 
THE  RESULTS  OF  THE  SCHEDULER.  THIS  PROCESS  HAS  AS 
INPUT  THE  PERIOD  OF  THE  PROCESS  THIS  PROSSES  USES 
THE  FUNCTION  "get_timing_inf o"  WHICH  RETURNS  THE 
TIME  THAT  THE  FUNCTION  WAS  CALLED.  THE  OUTPUT  OF 
THIS  PROCESS  IS  IN  THE  FILE  "out3"  WHERE  TIMIMG 
INFORMATION  IS  WRITEN. 

THE  TIMING  PROCESS  DIFFERS  ONLY  IN  THE  DELAY.  IT 
HAS  A  TIMING  SLEEP  EQUAL  TO  THE  PERIOD. 

THE  INITIALIZATION  PROCESS  IS  ALSO  SIMILAR.  THE 
DIFERENCE  IS  THAT  THERE  IS  NOT  MAIN  LOOP. 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


*********************** 


**********************************************/ 


•include 

<stdio .h> 

•include 

<errno .h> 

•include 

<modes .h> 

•include 

<signal  .h*. 

•include 

<procid.h> 

•define 

NUMBER 

4 

•define 

STATISTICS 

"out3" 

/* 

OUTPUT  FILE 

*/ 

•define 

STAT.INFOJ 

DELAY  394 

/* 

DELAY  OF  THE  PROGRAM 

*/ 

•define 

LOOP 

3160 

/* 

TIME  OF  ONE  TICK 

*/ 

•define 

TRUE 

1 

•define 

RUN 

50 

/* 

EXPECTED  TIMES  TO  RUN 

*/ 

char  *names [] *  {"/PIPE/current_posture" , "/PIPE/emergency_posture" , 
"/PIPE/ref erence.postures" , "/PIPE/ commanded.postures" , 0 , } ; 

extern  int  exit() ,pause() ,getpid() ,_get_process_desc() ,kill() ; 

char  *outbuf f er  [10] ={"3a" , "3b" , "3c" , "3d" , "3e" , 

"3f " , "3g" , "3h" , "3i" , "3j "} ; 


icpthand ( s ignum) 
int  6 ignum; 

{ 

/*  INTERCEPT  HANDLER  */ 

fprintf  (stderr,"I  received  in  guidance. c  signal  y,d\n" , s ignum)  ; 
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main(argc.argv) 
int  argc ; 

char  *argv  []  ; 

{ 

int  pipes [NUMBER] ; 

FILE  *statfile; 

char  buffer [10]; 

int  delay, i,j .count .killerr .pdata; 

period , readerr , Wr iteLength ; 
int  time.start [RUN] ,time_stop [RUN] , 

tick_start[RUN] ,tick_stop [RUN] ; 
short  int  parent id; 
unsigned  final  ..sleep ; 

void  get_timing_info() ; 

short  int  get_parent_id() ; 

intercept (icpthand) ; 
i- j  =0 ; 

count  *  0;  /*0PEN  THE  FILE  FDR  THE  RESULTS  */ 

statfile  *  f open(STATISTICS , "a") ; 

while (names [i] !=NULL){ 

if((pipes[i]  *  open (names [i] ,S_IREAD+S_I WRITE) )  **  -l){ 
fprintf (stderr, 

"\tThe  */,s  is  not  opening  in  '/.s  for  writing  \n" , 
names [i] ,argv [0]  ) ; 
exit (errno) ; 

>  /*0PEN  THE  PIPE  FOR  WRITING  */ 

i++; 

> 

delay  *  L00P*atoi (argv [l] ) -STAT_INFO_DELAY ; 

/♦CALCULATE  THE  DELAY  ACCORDING  TO  THE  EXEC.  TIME  IN  TICKS^/ 
parentid  =  get_parent_id(argv[0]) ; 

/♦  WAKE  UP  sched.c  */ 

if ((killerr*kill (parentid, SIGWAKE))  *==  -1) 

fprintf  (stderr,"  Cannot  wakeup  rm.c  in  */,s,  error  No  ='/,d\n", 

argv[0] , errno) ; 

pause () ;  /♦  WAIT  FOR  ALL  PROCESSES  TO  START  TOGETHER  */ 

while (j<RUN-l) 

{ 

get_timing_info(fttime_start [j] ,ttick_start [j]) ; 

/*  READ  PIPE  FROM  PERIODIC  PROCESS  */ 

if ((readerr  ■  readln(pipes[0] .buffer, 10))  ■*  -1) 

fprintf  (stderr,  "cannot  read  %s,in  %s,  error  number  y,d\n", 

names [0] , axgv [0] , errno) ; 
/♦  READ  PIPE  FROM  APERIODIC  PROCESS  */ 
if((  pdata  «  _gs_rdy(pipes[l]))  >  1){ 

if ((readerr  *  readln(pipes[l] .buffer, 10))  *■  -1) 
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fprintf (stderr, "cannot  read  '/.s,in  '/.s,  error  number  '/,d\n" , 

names [l] ,argv[0] , errno) ; 

/*  READ  PIPE  FROM  PERIODIC  PROCESS  */ 

if((readerr  *  readln (pipes [2] .buffer ,10))  *=  -1) 

fprintf (stderr ."cannot  read  '/.s,in  */.s,  error  number  Xd\n", 

names  [2]  ,  argv  [0]  ,  errno)  ; 
f or (i=l ; i<delay ; i++) ;  /*  INSTEAD  DF  THE  REAL  PROGRAM  */ 

/*  WRITE  IN  PIPE  */ 

if  ((WriteLength  ■  vriteln(pipes[3]  .outbuffer  [count*/,10]  ,10))  <  0) 
fprintf  (stderr,  "cannot  write  in  /,s,in  %s,  error  No  Xd\n", 

names [3] ,argv[0] , errno) ; 

get .timings inf o(4time_stop[j] ,4tick_stop[j] ) ; 

j++; 

> 

for(j=0; j<RUN-l; j++){  /*  THIS  IS  ONLY  FOR  EXPERIMENT  PURPOSES  */ 

fseek(statfile,0,2) ;  /*  FIND  THE  END  OF  THE  out3  FILE  */ 

fprintf ( st atf ile , 

"*/.s  for\t  */,d  time,  time:'/.6d-*/,6d,  ticks  y,6d-*/,6d  \n" , 
argv[0] , j ,time_start [j] ,time_stop[j] ,tick_start [j] , 

tick_stop[j]  )  ; 

>  /*  SAVE  THE  TIMING  INFORMATION  */ 

/*  SIGNAL  sched.c  THAT  FINISH  EXECUTION  */ 
if ((killerr=kill(parentid,SIGWAKE))  **  -1) 

fprintf  (stderr,  "Cannot  wakeup  rm.c  in  */,s,  error  No  “'/.d\n", 

argv[0] , errno) ; 

exit(O) ; 


Z^******************************************************************* 

*  THIS  FUNCTION  ACCESSES  THE  SYSTEM  CLOCK  AND  RETURNS  THE  TIME  AND  * 

*  THE  TICK.  * 

********* ************************ * *************** ******** * ** ** * ******/ 

void  get_timing_inf o (ret.time , ret_tick) 

int  *ret_time,*ret  tick; 

{ 

int  date, time, tick.mask; 

short  day; 

mask  =0x0000f f f f ; 

_sysdate(3,4time,4date,4day ,4tick) ; 

*ret_tick*(tick  4  mask); 

+ret_time=time; 
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/********************************************************************* 

*  THIS  FUNCTION  RETURNS  THE  PROCESS  I.D.  OF  THE  sched.c.  THE  * 

*  ARGUMENT  NAME  IS  ONLY  FOR  ERROR  HANDLING.  * 

********************★************************************************/ 
short  int  get_parent_id(name) 

char  *name ; 

{ 

int  gpiderr; 

short  int  pid; 
procid  parent; 

if  ((pid  =  getpidQ)  ==  -1)/*  TAKE  THE  PROCESS  I.D.  */ 

fprintf (stderr ,  "Cannot  get  Process  ID  in  */,s,  error  No*  */.d\n" , 

name.errno) ; 

/*  TAKE  THE  PARENTS  (sched.c)  I.D.  */ 

if ((gpiderr  *  _get_process_desc(pid,sizeof (parent) .ftparent))  *=  -1) 
fprintf (stderr, 

"Cannot  get  Process  Descriptor  in  */.s,  error  No=  y.d\n", 

name.errno) ; 

return (parent . _pid) ;  /*  RETURN  THE  PARENTS  I.D.  */ 

> 
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APPENDIX  D:  CODE  CREATING  THE  PIPES 


/********************************************************************* 


*  Program  :  PIPES. C  * 

*  Purpose  :  MAIN  CODE  PROCESS  THAT  CREATES  PIPES.  * 

*  Author  :  LTJG  D.  MAKRIS  H.N.  * 

*  Description:  THIS  PROGRAM  CREATES  ALL  THE  PIPES  THAT  WILL  BE  * 

*  USED  FOR  THE  PROCESS  COMMUNICATION.  AFTER  THE  * 

*  CREATION  THE  PROGRAMM  REMAINS  IDLE  UNTIL  THE  SET  * 

*  FINISHES.  OTHERWISE  PIPES  WILL  CLOSE.  * 


**  4^* ***************************************************** ***********/ 


•include 

<stdio .h> 

•include 

<errno .h> 

•include 

<modes .h> 

•include 

<signal .h> 

•include 

<procid.h> 

•define 

MAXSIZE  20 

•define 

NUMBER  16 

/*  1 

char  *names[]=  {"/PIPE/token 

*/ 


"/PIPE/signals" , "/PIPE/positions" , 

"/PIPE/ current .posture" ,"/PIPE/emergency_posture" , 
"/PIPE/inertial_data" , "/PIPE/obstacle_ alert" , 
"/PIPE/alert" , "/PIPE/path" , 

"/PIPE/ range.data" , "/PIPE/ref erence.postures" , 
"/PIPE/replan_request" , "/PIPE/ sonar.data" , 

"/PIPE/ status" , "/PIPE/ systems.status" ,0 ; 


extern  int  exitO  ,pause()  ,getpid()  ,_get_process_desc()  , 
kill () , intercept () ; 

icpthand(signum) 
int  signura; 

/*  INTERCEPT  HANDLER  */ 

fprintf (stderr,"I  received  signal  in  pipes. c  :  %d\n" ,signum) ; 


main(argc.argv) 
int  argc ; 

char  *argv[]  ; 


FILE 

int 

short  int 


*pipes [NUMBER] ; 
killerr , i ; 
parent id; 


85 


short  int  get_parent_id() ; 


intercept (icpthand) ; 
i=0; 

while (names [i] !=NULL){  /*  OPEN  ALL  THE  PIPES  LIKE  FILES  */ 

if((pipes[i]  =  f open (names [i]  ,"w"))  ==  NULL){ 

fprintf (stderr, "Cannot  open  */,s. Error  '/,d  \n\n  ", 

names [i] ,errno) ; 

exit (errno) ; 

> 

i++; 

> 

parentid  *  get_parent_id(argv[0] ) ;/*  FIND  PARENTS  I.D. 

CODE  HAS  DEFINED  IN  APPEMDIX  C  */ 
/*  SIGNAL  sched.c  THAT  INITIALIZATION  FINISHED  */ 
if((killerr  =  kill (parentid, SIGWAKE))  **  -1) 

fprintf  (stderr,  "Cannot  vakeup  rm.c  in  '/,s,  error  No  =%d\n" , 

argv[0] , errno) ; 

pause () ;  /*  WAIT  OTHERWISE  PIPES  WILL  CLOSE  */ 

exit (0) ; 


t 
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